Re: [HACKERS] Re: [QUESTIONS] Arrays (inserting and removing)

Hi all! I'm back :)
[and was bit by the varchar() bug so you can ignore earlier message..
that's what I get for not reading pg-hackers for 2 months... but still
updating from CVS *sigh*]

On Wed, 14 Jan 1998, Thomas G. Lockhart wrote:

> > > I think what's going on is a shift away from the OR-model. A
> > > lot of the OO features come from Postgres non-relational past.
> > > I don't see a lot of development emphasis on the OO side :-(
> > > mostly people work on getting PostgreSQL more ANSI-sql conforming.
> > > This by itself is very nice, but i think it would be a good
> > > idea for the developers to make a public statement saying
> > > how they envision PostgreSQLs future (i.e. will it still support
> > > the OO features or not).
>
> OO and OR are not the same. Postgres is definitely OR, and definitely not OO
> (yet).

So what does it need / what should I read to see what the TODO for
OO-compatibility?

I've seen a lot of data to suggest that -Postgres- is the heart of most OO
databases... or at least a very strong influence.
[especially after reading the history of OO database research :]

> > we (the developers) are addressing problems as ppl are
> > bringing them up, and adding in those features required to bring in
> > ANSI-SQL compliancy...
>
> Yes, at this stage of Postgres' career, the main emphasis *from a user's
> point of view* is on moving the parser and the backend capabilities toward
> SQL92/3 compliance and on fixing broken features. A year ago, the main
> emphasis was on getting the backend to stop crashing. I would guess that the
> next 6 months/year will continue to see work on SQL compliance and backend
> performance, but after that the project will move on to getting more OO in
> the OR features. Just a guess though...

Good - enough time for me to start working .... :)

> However, we have been pretty clear in the hackers discussions that we will
> not sacrifice _any_ of the OR/OO features of Postgres solely to obtain
> compliance with bad/ugly/stupid features of the standard. Also, we consider
> any feature which damages OR as being bad and ugly and stupid...

*grin* - good additude! :)

> > That said, does ANSI-SQL compliancy mean that the OR model no
> > longer has a place?
>
> Naw, SQL3 has some OR features (many demonstrated by Postgres 5 years
> earlier). It's the wave of the future...

Yep - Postgres was the testcase for all of those OR features :)
[read : postgres was used to design them]
The work was too leading-edge for the database people to bother looking...
(but guess where "Datablades" came from :)

> > Quite frankly, I haven't got a clue...since I've
> > never used it. What I would recommend is anyone *actually* using it
> > should pop onto the pgsql-hackers mailing list, where this sort of stuff
> > is discussed, so that if someone does bring up removing a feature because
> > there doesn't appear to be any apparent use for it, they can pop up and
> > recommend against it.
>
> The only case of a deprecated feature in the last year of development was the
> removal of "time travel" which was done not for standards compliance but for
> performance reasons (and only after extensive discussions on the questions
> list where it was not generally felt to be an important feature).

Time travel has it's uses... but can be implemented using standard hooks
if ever needed. Though it was considered of paramount importance to the
people who were working on postgres way back. (for data reliability and
recoverability).

I don't miss it (I am implementing it using standard SQL :)

> > I guess as far as that is concerned, is there anything that should
> > be added to the current regression tests that *test* whether we break some
> > part of the OR model?
>
> Already there. Don't sweat it...
>
> There has been reluctance on the part of the current developers to write a
> "future directions" statement because, as volunteers, we really can't
> _guarantee_ the behavior of future developers. Also, future development
> requires that someone actually do the work, and if someone has stated that
> they are going to work on a feature but then must drop from the project for
> personal reasons (yes, sometimes there is more to life than Postgres) there
> is not some new developer guaranteed to take his place.
>
> However, imho it is appropriate to write a future directions statement which,
> for example, applies to the next few releases, or which is reevaluated from
> time to time.

heh. Life is why I never got to "ALTER TABLE DROP <column" yet... That
and I'm still learning how postgres is put together in my copious free
time *grin*.... (is it still needed?)

G'day, eh? :)
- Teunis