Skip site navigation (1) Skip section navigation (2)

Re: RFD: PostgreSQL Schema Support

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: "'Tim Finch, FosterFinch Ltd'" <tim(at)fosterfinch(dot)co(dot)uk>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: RFD: PostgreSQL Schema Support
Date: 2002-04-05 19:35:32
Message-ID: FED2B709E3270E4B903EB0175A49BCB1293359@dogbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: Tim Finch, FosterFinch Ltd [mailto:tim(at)fosterfinch(dot)co(dot)uk] 
> Sent: 05 April 2002 17:23
> To: Dave Page
> Cc: pgadmin-hackers(at)postgresql(dot)org
> Subject: Re: [pgadmin-hackers] RFD: PostgreSQL Schema Support
> 
> 
> At 13:40 05/04/2002 +0100, Dave Page wrote:
> >I'm currently starting to implement support for some of the more 
> >desirable features of PostgreSQL 7.3 which is now well in 
> development. 
> >One of these
> 
> I wish the desirable features for 7.3 included all of alter table 
> implemented. Do you know if it is BTW? A bit out of touch 
> with the 'to do' 
> and 'Now done' lists.

The problem with the PostgreSQL todo list (as with most open source
projects), is that the developers pick what they want to work on, which is
not necessarily what the less experienced users want. Net result is that
releases are planned by time scale rather than when the todo list is clear.

On the plus side, I noticed that Hiroshi cleared out the DROP_COLUMN_HACK
stuff the other day, and Tom Lane (I think) did write up some ideas for
handling DROP COLUMN using historic versions of tuple types. Also (I think
it was Christopher Kings-Lynne & Tom Lane) were discussing implementing some
of the known pg_attribute hacks as real SQL the other day.

> >There are a number of ways we could implement this, and I'd 
> like to get 
> >some feedback on what people think is right.
> 
> Tricky.
> My gut feeling is get the classes / object model as close as 
> possible to 
> what PostgreSQL exposes. As stated for 7.2 and before this is 
> one thing, 
> for 7.3 onwards its another.
> 
> Perhaps you can freeze pgAdminII code base at some soon 
> point, make it 
> known this is where support for 7.2 and earlier ends, and 
> move the version 
> number up a notch and follow through with the 7.3 only route 
> from here on 
> in? Perhaps for a season offer bug fixe releases only to the 
> frozen 7.2 
> version, with a cut off date, roughly in keeping with the 
> expected adoption 
> rate of 7.3. For us mere NT/2000 folk, perhaps also wait 
> until 7.3 is out 
> on Cygwin, too before freezing all support for 7.2.

I'd rather not do this if I can help it. Periodically with pgAdmin I we had
to bump the minimum version number and I never liked doing it, not just
because of the extra support posts, but it just seemed restrictive.

Actually, I think Rod's idea is a good one. We go with option 2 & fudge a
PUBLIC schema for PostgreSQL < 7.3. Actually, this is how Tom Lane is
handling backwards compatibility in PostgreSQL - he's using a PUBLIC schema
which will be used by default. We'd just do it the other way round.

> Ahhh, the wonderful world of open source.... Its like looking 
> at the best 
> countryside in full clarity..... but whilst sitting on a 
> train, the view always keeps shifting..

:-) That's the problem with tools like pgAdmin that are tied so tightly to a
separate project.

Regards, Dave.

pgadmin-hackers by date

Next:From: Dave PageDate: 2002-04-05 19:40:10
Subject: Re: RFD: PostgreSQL Schema Support
Previous:From: Rod TaylorDate: 2002-04-05 19:26:17
Subject: Re: RFD: PostgreSQL Schema Support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group