Here are the major open issues for 7.0 that I remember:

	Foreign Keys   - Jan
	WAL            - Vadim
	Function args  - Tom
	System indcxes - Bruce
	
Outer joins and new multi-query parse tree are questionable items for
7.0.

Is this currect?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 18 Nov 1999 22:43:15 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
7.0 status request
> Here are the major open issues for 7.0 that I remember:
>         Foreign Keys   - Jan
>         WAL            - Vadim
>         Function args  - Tom
>         System indcxes - Bruce
> Outer joins and new multi-query parse tree are questionable items for
> 7.0.

You might include "join syntax", which will be ready even if outer
joins are not.

Also, didn't some folks express concern that indices on system tables
would make the backend more fragile? Did we resolve that issue?

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Fri, 19 Nov 1999 06:35:59 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] 7.0 status request
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here are the major open issues for 7.0 that I remember:
> 	Foreign Keys   - Jan
> 	WAL            - Vadim
> 	Function args  - Tom
> 	System indcxes - Bruce
> Outer joins and new multi-query parse tree are questionable items for
> 7.0.

I have a bunch of optimizer tweaking that I'd like to finish before 7.0,
but perhaps that doesn't qualify as a major open issue.  There's no
single item there that I would rank as "must fix or don't ship"; yet
I feel we need to make some progress in that area.

I think there are also a lot of unresolved questions about interlocking
and updating of the catalog caches and relcache.  These might be
must-fix items.  IIRC, Hiroshi is pretty concerned about that area...

			regards, tom lane

Fri, 19 Nov 1999 02:02:45 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 7.0 status request 
> > Here are the major open issues for 7.0 that I remember:
> >         Foreign Keys   - Jan
> >         WAL            - Vadim
> >         Function args  - Tom
> >         System indcxes - Bruce
> > Outer joins and new multi-query parse tree are questionable items for
> > 7.0.
> 
> You might include "join syntax", which will be ready even if outer
> joins are not.
> 
> Also, didn't some folks express concern that indices on system tables
> would make the backend more fragile? Did we resolve that issue?

We have indexes on most system tables and it isn't a problem currently.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 19 Nov 1999 07:28:43 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 7.0 status request
Bruce Momjian wrote:
> 
> Here are the major open issues for 7.0 that I remember:
[snip] 
> Is this currect?

Is large tuple support not open at this time?  I know it is one of the
things that has been wanted for ages.  I know a discussion about it
happened not long ago, but no one stepped up to the plate on it.

--
Lamar Owen
WGCR Internet Radio

Fri, 19 Nov 1999 12:24:51 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] 7.0 status request
Bruce Momjian wrote:

> > > Here are the major open issues for 7.0 that I remember:
> > >         Foreign Keys   - Jan
> > >         WAL            - Vadim
> > >         Function args  - Tom
> > >         System indcxes - Bruce
> > > Outer joins and new multi-query parse tree are questionable items for
> > > 7.0.
> >
> > You might include "join syntax", which will be ready even if outer
> > joins are not.
> >
> > Also, didn't some folks express concern that indices on system tables
> > would make the backend more fragile? Did we resolve that issue?
>
> We have indexes on most system tables and it isn't a problem currently.

    It  is, because a corrupted index on a system table cannot be
    corrected by drop/create, as a user defined index could be.

    I don't know why and when  reindexdb  disappeared,  but  that
    script  was  a  last  resort  for  exactly the situation of a
    corrupted  system  index.   Let  me  take  a  look  if   this
    functionality could easily be recreated.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Fri, 19 Nov 1999 20:55:14 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] 7.0 status request
On Fri, Nov 19, 1999 at 08:55:14PM +0100, Jan Wieck wrote:
> 
>     It  is, because a corrupted index on a system table cannot be
>     corrected by drop/create, as a user defined index could be.
> 
>     I don't know why and when  reindexdb  disappeared,  but  that
>     script  was  a  last  resort  for  exactly the situation of a
>     corrupted  system  index.   Let  me  take  a  look  if   this
>     functionality could easily be recreated.
> 

Jan,

I submitted a very small patch to dumpdb that creates SQL that will
reindex the database.  It's then trivial to then redirect that output to
pgsql on UNIX.  I run into this problem frequently, so I wanted
to automate the process.  I never saw a reply to my post on the list,
so I wonder if it made it.  

I'm not sure how reindexdb worked, but if it just generated SQL based of 
the indexes in the database it would make sense to only have the SQL 
generation in one common place instead of having it in dumpdb and reindexdb.
Two branches of nearly identical code would be a pain to maintain.  

-brian

-- 
The world's most ambitious and comprehensive PC game database project.

                      http://www.mobygames.com

Fri, 19 Nov 1999 15:41:49 -0600
Brian Hirt <bhirt@mobygames.com>
Re: [HACKERS] 7.0 status request
> Bruce Momjian wrote:
> > 
> > Here are the major open issues for 7.0 that I remember:
> [snip] 
> > Is this currect?
> 
> Is large tuple support not open at this time?  I know it is one of the
> things that has been wanted for ages.  I know a discussion about it
> happened not long ago, but no one stepped up to the plate on it.

No one has claimed it.  It may be too hard.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 19 Nov 1999 16:49:15 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 7.0 status request

On 19-Nov-99 Bruce Momjian wrote:
> Here are the major open issues for 7.0 that I remember:
> 
>       Foreign Keys   - Jan
>       WAL            - Vadim
>       Function args  - Tom
>       System indcxes - Bruce
>       
> Outer joins and new multi-query parse tree are questionable items for
> 7.0.
> 
> Is this currect?

There was talk about purging functions from libpq.  Is there any concensus
on which functions may be going away?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================



Fri, 19 Nov 1999 16:56:59 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
RE: [HACKERS] 7.0 status request
Lamar Owen <lamar.owen@wgcr.org> writes:
> Bruce Momjian wrote:
>> Here are the major open issues for 7.0 that I remember:

> Is large tuple support not open at this time?

I think Bruce was trying to list the work items that are both large
and fairly likely to be done before 7.0.  (I suspect his motivation
is to figure out what changes he should allow for while writing his
book...)

No one has spoken up and said "I will work on large tuples for 7.0",
so it's not on his list.  It could still happen though.

			regards, tom lane

Fri, 19 Nov 1999 17:14:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 7.0 status request 
> I submitted a very small patch to dumpdb that creates SQL that will
> reindex the database.  It's then trivial to then redirect that output to
> pgsql on UNIX.  I run into this problem frequently, so I wanted
> to automate the process.  I never saw a reply to my post on the list,
> so I wonder if it made it.
>
> I'm not sure how reindexdb worked, but if it just generated SQL based of
> the indexes in the database it would make sense to only have the SQL
> generation in one common place instead of having it in dumpdb and reindexdb.
> Two branches of nearly identical code would be a pain to maintain.

    It's  a  different  approach.  And  recreating system catalog
    indices cannot work through the regular  psql  interface.  So
    your pgdump enhancement will never be able to do that.

    You  need  to  be  in  bootstrap processing mode (the one the
    system is running in while initdb) to drop or create  indices
    on  the  system catalog tables. Therefore the postmaster must
    NOT be running and you have a (very limited) interface to the
    bootstrapping  postgres process. Thus you'll have to talk the
    *.bki.source dialect to issue commands.

    I already made some tests, but they all corrupted  more  than
    they  fixed  :-).   Seems  the  semantics of the Postgres 4.2
    reindexdb have been hit by changes in  index  handling  since
    1994. Not really surprising to me.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Fri, 19 Nov 1999 23:17:39 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] 7.0 status request
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Bruce Momjian wrote:
> >> Here are the major open issues for 7.0 that I remember:
> 
> > Is large tuple support not open at this time?
> 
> I think Bruce was trying to list the work items that are both large
> and fairly likely to be done before 7.0.  (I suspect his motivation
> is to figure out what changes he should allow for while writing his
> book...)

Actually, the motivation was to just get a heads-up from everyone that
we are on track for 7.0.  If someone wanted to cancel their offer of
adding a feature, that is usually the way we hear about it.  That way,
we don't find out just before beta that someone has decided to abandon a
feature addition.

This doesn't mean they will actually complete the addition, but it does
mean that at this time they are going to attempt to complete it for 7.0.

As we get closer, the dreaded Open Items list appears to marshall forces
to get as many bugs fixed/features as possible, though Tom, your
presence is making that unnecessary because you seem to fix the bugs
as soon as they come up. In the old days, the stuff stayed in my
mailbox, and nearing beta, I would comb through for open bug reports,
make a list, and try and get as many fixed as possible.

BTW, I am writing the book assuming no additions will be made for 7.0.
If they happen, I will rewrite.  If I put a feature on paper, there is
extra pressure to complete it, and I don't want to do that.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 19 Nov 1999 17:39:52 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 7.0 status request
On 1999-11-19, Vince Vielhaber mentioned:

> There was talk about purging functions from libpq.  Is there any concensus
> on which functions may be going away?

As far as I'm concerned, the printing functions only have a few more weeks
to live ;)

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Sat, 20 Nov 1999 03:19:49 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
RE: [HACKERS] 7.0 status request
On 1999-11-18, Bruce Momjian mentioned:

> Here are the major open issues for 7.0 that I remember:

Does anyone ever plan on dropping any columns? I think this is a must-have
for the latest and greatest database system. I'm sure an experienced
backend hacker can put something together in a few days. If need be we
could just use a radical solution similar to cluster where you have to
shut down the whole database and rebuild all indices afterwards, but
pleeeeease.

Or this forgotten? Impossible? A feature?

Just wondering . . .

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Sat, 20 Nov 1999 03:56:19 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: [HACKERS] 7.0 status request
> >> Here are the major open issues for 7.0 that I remember:
> I think Bruce was trying to list the work items that are both large
> and fairly likely to be done before 7.0.  (I suspect his motivation
> is to figure out what changes he should allow for while writing his
> book...)

Ah, that reminds me...

I will do a "type reunification" for the date/time types, hopefully by
the end of December. I consider this fairly important and have been
holding off for a major release to do it...

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Sat, 20 Nov 1999 03:13:36 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] 7.0 status request
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> Sent: Friday, November 19, 1999 4:03 PM
> To: Bruce Momjian
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] 7.0 status request 
> 
> I think there are also a lot of unresolved questions about interlocking
> and updating of the catalog caches and relcache.  These might be
> must-fix items.  IIRC, Hiroshi is pretty concerned about that area...
>

Unfortunately I don't have a reasonable solution for interlocking yet.
First,row level locking for system tuples not only exclusive but
also shared will be needed. I couldn't find the way to implement
shared row level locking now. 
Moreover I'm suspicious that this row level locking could be used
for parser/planner. Row level locking(at least in current implemen
tation) is held till end of transaction.

As for cache invalidation(rollback),I may be able to do something.
However new save point feature would need some change around
it.  I don't know how Vadim would change it. 

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp  


Tue, 23 Nov 1999 07:04:27 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: [HACKERS] 7.0 status request 
Hiroshi Inoue wrote:
> 
> As for cache invalidation(rollback),I may be able to do something.
> However new save point feature would need some change around
> it.  I don't know how Vadim would change it.

I have no plans to implement it for 7.0...

Vadim

Tue, 23 Nov 1999 09:50:24 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] 7.0 status request
> -----Original Message-----
> From: root@sunpine.krs.ru [mailto:root@sunpine.krs.ru]On Behalf Of Vadim
> Mikheev
> Sent: Tuesday, November 23, 1999 11:50 AM
> To: Hiroshi Inoue
> Cc: Tom Lane; Bruce Momjian; PostgreSQL-development
> Subject: Re: [HACKERS] 7.0 status request
> 
> 
> Hiroshi Inoue wrote:
> > 
> > As for cache invalidation(rollback),I may be able to do something.
> > However new save point feature would need some change around
> > it.  I don't know how Vadim would change it.
> 
> I have no plans to implement it for 7.0...
>

Doesn't ROLLBACK to a save point rollback catalog cache ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp 

Tue, 23 Nov 1999 12:20:57 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: [HACKERS] 7.0 status request
Hiroshi Inoue wrote:
> 
> > > As for cache invalidation(rollback),I may be able to do something.
> > > However new save point feature would need some change around
> > > it.  I don't know how Vadim would change it.
> >
> > I have no plans to implement it for 7.0...
> >
> 
> Doesn't ROLLBACK to a save point rollback catalog cache ?

There will be no savepoints in 7.0...
But I'm going to rollback all changes made by xaction
on abort...

Vadim

Tue, 23 Nov 1999 10:20:59 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] 7.0 status request
> > Hiroshi Inoue wrote:
> > > 
> > > As for cache invalidation(rollback),I may be able to do something.
> > > However new save point feature would need some change around
> > > it.  I don't know how Vadim would change it.
> > 
> > I have no plans to implement it for 7.0...
> >
> 
> Doesn't ROLLBACK to a save point rollback catalog cache ?

I thought we flush cache on abort, no?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 22 Nov 1999 22:38:06 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] 7.0 status request
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: Tuesday, November 23, 1999 12:38 PM
> To: Hiroshi Inoue
> Cc: Vadim Mikheev; Tom Lane; PostgreSQL-development
> Subject: Re: [HACKERS] 7.0 status request
> 
> 
> > > Hiroshi Inoue wrote:
> > > > 
> > > > As for cache invalidation(rollback),I may be able to do something.
> > > > However new save point feature would need some change around
> > > > it.  I don't know how Vadim would change it.
> > > 
> > > I have no plans to implement it for 7.0...
> > >
> > 
> > Doesn't ROLLBACK to a save point rollback catalog cache ?
> 
> I thought we flush cache on abort, no?
>

Sorry,I don't remember well now.
But  at least catalog cache is not rollbacked for the transaction
itself in case of abort.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Tue, 23 Nov 1999 13:17:29 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: [HACKERS] 7.0 status request