Thread: Open 7.3 items

Open 7.3 items

From
Bruce Momjian
Date:
As you can see, the open items list is greatly shrunk.  We have two
weeks to go and most of these seems do-able, except for point-in-time
recovery, which may not make it.  I haven't heard anything recently on
it.

Would someone put together a porting document for schema changes and
drop column changes?

---------------------------------------------------------------------------                             P O S T G R E S
QL
 
                         7 . 3  O P E N    I T E M S


Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.

Source Code Changes
-------------------
Point-in-time recovery - status? (J.R., Richard)
Schema handling - ready? interfaces? client apps?
Drop column handling - ready for all clients, apps?
ecpg and bison issues - solved?  (Michael)
have pg_dumpall dump out db privilege and per-user/db settings
fix implicit type coercions that are worse
Prepared statements - to be reviewed  (Tom)
improve macros in new tuple header code  (Tom)
integrate or move to gborg libpqxx, Pg:DBD
Allow PL/PgSQL functions to return sets  (Neil)
Allow easy display of usernames in a group (pg_hba.conf uses groups now)
fix BeOS and QNX4 ports

Documentation Changes
---------------------
Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables
Document need to add permissions to loaded functions and languages

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Open 7.3 items

From
"Jeroen T. Vermeulen"
Date:
On Sat, Aug 17, 2002 at 11:08:45PM -0400, Bruce Momjian wrote:
> 
> integrate or move to gborg libpqxx, Pg:DBD

It's no longer my CVS home tree...  Is there something I can/should 
do for this?


Jeroen



Re: Open 7.3 items

From
Bruce Momjian
Date:
Yes, this is the counter case, where the '@' disappears;  so it appears
magically for local users, and disappears for global users.

---------------------------------------------------------------------------

Robert Treat wrote:
> Is the converse to this:
> 
> $ psql -U postgres@ test
> 
> Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
>         
>         Type:  \copyright for distribution terms
>                \h for help with SQL commands
>                \? for help on internal slash commands
>                \g or terminate with semicolon to execute query
>                \q to quit
>         
>         test=> select current_user;
>          current_user 
>         --------------
>          postgres
>         (1 row)
> 
> 
> this seems counterintuitive to me, so I'd like to see the strong
> practical application that makes it necessary. (This is where mark comes
> in I suppose)
> 
> Robert Treat
> 
> On Tue, 2002-08-27 at 15:43, Bruce Momjian wrote:
> > Lamar Owen wrote:
> > > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> > > > I think we need to resolve this discussion from a week ago.  The current
> > > > code is this:
> > > 
> > > I thought it WAS resolved, to do:
> > > 
> > > >     global usernames are stored just like before, e.g. postgres
> > > >     local users are stored as user@dbname
> > > >     when connecting, global users add '@' to their names
> > > >     when connecting, local users use just their user name, no @dbname
> > > 
> > > > Tom likes this because it is the fewer global users who have to append
> > > > the '@'.
> > > 
> > > At least that was my perception of the uneasy consensus reached.
> > > 
> > > Basically, this tags the @ as magic saying, during the client connect process, 
> > > 'I'm GLOBAL, treat me differently'.  Now that I actually understand how this 
> > > is supposed to work, which your four lines above elucidate nicely, I am in 
> > > more agreement than I was that this is the right answer to this issue.
> > 
> > OK, you have now split the vote because we have two for the change, and
> > two against.  Why do you prefer to tag the globals?  Is it Tom's
> > argument?  I think it is kind of strange to tag the globals when it is
> > the locals who have @ in their username, and when they do:
> > 
> >     $ psql -U dave test
> >     Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
> >     
> >     Type:  \copyright for distribution terms
> >            \h for help with SQL commands
> >            \? for help on internal slash commands
> >            \g or terminate with semicolon to execute query
> >            \q to quit
> >     
> >     test=> select current_user;
> >      current_user 
> >     --------------
> >      dave@test
> >     (1 row)
> > 
> > they will see their full username.
> > 
> > I can go either way.  I am just saying we need to hear from more people
> > to make sure we are doing this properly.
> > 
> > -- 
> >   Bruce Momjian                        |  http://candle.pha.pa.us
> >   pgman@candle.pha.pa.us               |  (610) 359-1001
> >   +  If your life is a hard drive,     |  13 Roberts Road
> >   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> > 
> > http://www.postgresql.org/users-lounge/docs/faq.html
> 
> 
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Open 7.3 items

From
One Way
Date:
Tom Lane: "And with the availability of schemas in 7.3, I think that
multiple databases per installation is going to become less common to
begin with --- people will more often use multiple schemas in one big
database if they want the option of data sharing, or completely
separate installations if they want airtight separation."

This is not a good assumption, in my opinion. Normally, one app is
associated with one database. This way, if something happens to the db,
only one application is unavailable, others will not be affected, more
or less. Besides, some databases are huge, so recovery time may take a
long time. If everything is in one db, the whole organization will be
brought to a halt, all apps will be down for a while. From my
experience, this will not be considered acceptable in any reasonable
organization.
This is the place where cross-db queries become critically important.
You do not want to duplicate data in several databases and, at the same
time, you do not want to have one huge unmanageable db that can
potentially bring down all your apps.

my $0.02


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com