Re: [QUESTIONS] Arrays (inserting and removing)

> > 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).

> Nobody is actively *removing* OO features...or at least not that
> I'm aware of...

Nobody's even doing it secretly :)

> 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...

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...

> 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...

> 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).

The only other discussions I can recall of "feature removal" involve the
possibility of removing some of the "specialty character types" like char16
since one can achieve an identical or better result with other existing
standard or quasi-standard types like varchar() and text(). There may be
other cases of "type consolidation" in the future as we work to avoid "type
bloat".

> 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.

- Tom