Обсуждение: Re: [QUESTIONS] Arrays (inserting and removing)

On Wed, 14 Jan 1998, Ralf Mattes wrote:

> Yes, i agree. Mike's implementation is the way to go in a traditional
> realtional db (BTW, a question about oids: lurking on this list
> i overheard the idea of dropping oids. This would break a lot
> of my code! What's the last word on this ?).

    The last we discussed in pgsql-hackers was that OIDs would not be
dropped...

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

    Nobody is actively *removing* OO features...or at least not that
I'm aware of...we (the developers) are addressing problems as ppl are
bringing them up, and adding in those features required to bring in
ANSI-SQL compliancy...

    That said, does ANSI-SQL compliancy mean that the OR model no
longer has a place?  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.

    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?

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

The Hermit Hacker wrote:
>
> On Wed, 14 Jan 1998, Ralf Mattes wrote:
>
> > Yes, i agree. Mike's implementation is the way to go in a traditional
> > realtional db (BTW, a question about oids: lurking on this list
> > i overheard the idea of dropping oids. This would break a lot
> > of my code! What's the last word on this ?).
>
>         The last we discussed in pgsql-hackers was that OIDs would not be
> dropped...

..but would be optional.

Vadim

On Thu, Jan 15, 1998 at 09:27:21AM +0700, Vadim B. Mikheev wrote:
> The Hermit Hacker wrote:
> >
> > On Wed, 14 Jan 1998, Ralf Mattes wrote:
> >
> > > Yes, i agree. Mike's implementation is the way to go in a traditional
> > > realtional db (BTW, a question about oids: lurking on this list
> > > i overheard the idea of dropping oids. This would break a lot
> > > of my code! What's the last word on this ?).
> >
> >         The last we discussed in pgsql-hackers was that OIDs would not be
> > dropped...
>
> ..but would be optional.
>
> Vadim
>

OIDs are a bastardization of the relational model.  If you have to keep
them, then do so, but their use should be SEVERELY discouraged.

--
--
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly to FULL DS-3 Service
                 | NEW! K56Flex support on ALL modems
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost

> OIDs are a bastardization of the relational model.  If you have to keep
> them, then do so, but their use should be SEVERELY discouraged.

    Actually, I use them quite extensively...I have several WWW-based
search directories that are searched with:

select oid,<fields> from <table> where <search conditions>;

    That display minimal data to the browser, and then if someone
wants more detailed information, I just do:

select * from <table> where oid = '';

    Its also great if you mess up the original coding for a table and
want to remove 1 of many duplicates that you've accidently let pass
through :(

Thus spake The Hermit Hacker
> > OIDs are a bastardization of the relational model.  If you have to keep
> > them, then do so, but their use should be SEVERELY discouraged.

I agree although I do use them in some library routines (Tcl and Python)
that I use in a get/update cycle.  The way it is set up though, the calling
routine is never aware of the use of OIDs.  It's almost like part of the
database engine as far as the routine is concerned.

example:

from pg import *
from dbgen import *
db = connect('table')
user = db_get(db, 'user', 100)
user['name'] = 'Joe'
db_update(db, 'user', user)

The db_get puts the oid into the Python dictionary and the db_update uses
that to update the same record.  The caller never sees it.

Note:  Of course I realize that a simple SQL statement will do this.  It's
a contrived example.

>     Actually, I use them quite extensively...I have several WWW-based
> search directories that are searched with:
>
> select oid,<fields> from <table> where <search conditions>;
>
>     That display minimal data to the browser, and then if someone
> wants more detailed information, I just do:
>
> select * from <table> where oid = '';

But really there should be a proper key on this database.  I think that
that's what Karl was getting at.  If you need a unique ID number then
you should really create one and make it a unique index on the table.

>     Its also great if you mess up the original coding for a table and
> want to remove 1 of many duplicates that you've accidently let pass
> through :(

With unique keys this shouldn't really be a problem.  In fact, the entire
record can be a complex key if necessary (I have done this on small
tables) so it should always be possible.  If you can still get dups
with the entire record keyed then just add an extra, non-keyed field
which holds the count.

--
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

On Thu, 15 Jan 1998, D'Arcy J.M. Cain wrote:

> >     Actually, I use them quite extensively...I have several WWW-based
> > search directories that are searched with:
> >
> > select oid,<fields> from <table> where <search conditions>;
> >
> >     That display minimal data to the browser, and then if someone
> > wants more detailed information, I just do:
> >
> > select * from <table> where oid = '';
>
> But really there should be a proper key on this database.  I think that
> that's what Karl was getting at.  If you need a unique ID number then
> you should really create one and make it a unique index on the table.
>

    This stuff was all built "pre unique index"...and we all know what
its like to go in and "Rebuild" something that is already working :(

On Thu, 15 Jan 1998, Karl Denninger wrote:

> > >         The last we discussed in pgsql-hackers was that OIDs would not be
> > > dropped...
> >
> > ..but would be optional.
> > Vadim

Phew, safed some code... :-)

> OIDs are a bastardization of the relational model.  If you have to keep
> them, then do so, but their use should be SEVERELY discouraged.

Yes, shure, but Postgres (and many com. systems) isn't afull im-
plementation of the relational model. And sometimes i's very handy
to be able ti identify a specific record/tuple (i use them in front
end user interfaces. The interface stores the oid of the currently
displayed record--if the user changes/deletes the record it's easy
to do an update/delete. Even so it's possible to store the unique
index key this is much more elaborate to implement and is a pain
when the table definitions aren't hardcoded in the frontend
application). I don't see why oids per se violate the relational
model (and of course when some of my dbs started there was nothing
like 'unique key' in postgres and in some theunique key stretches
over several fields...(

Ralf


===========================================================================
Ralf Mattes
Joh.-Seb.- Bach Str. 13
D-79104 Freiburg i. Br.
email: Mattes@MHS.uni-freiburg.de / Ralf@slon.freinet.de
===========================================================================

On Thu, Jan 15, 1998 at 10:58:22PM +0000, Ralf Mattes wrote:
> On Thu, 15 Jan 1998, Karl Denninger wrote:
>
> > > >         The last we discussed in pgsql-hackers was that OIDs would not be
> > > > dropped...
> > >
> > > ..but would be optional.
> > > Vadim
>
> Phew, safed some code... :-)
>
> > OIDs are a bastardization of the relational model.  If you have to keep
> > them, then do so, but their use should be SEVERELY discouraged.
>
> Yes, shure, but Postgres (and many com. systems) isn't afull im-
> plementation of the relational model. And sometimes i's very handy
> to be able ti identify a specific record/tuple (i use them in front
> end user interfaces. The interface stores the oid of the currently
> displayed record--if the user changes/deletes the record it's easy
> to do an update/delete. Even so it's possible to store the unique
> index key this is much more elaborate to implement and is a pain
> when the table definitions aren't hardcoded in the frontend
> application). I don't see why oids per se violate the relational
> model (and of course when some of my dbs started there was nothing
> like 'unique key' in postgres and in some theunique key stretches
> over several fields...(
>
> Ralf

Unique indices over multiple fields are both legal and work, and do what you
would expect.

I understand why people like OIDs - "row numbers" are useful to lots of
folks.  That doesn't change the fact that they are a throwback and I can't
find much of a good reason to use them in a relational world.

I've done a *lot* of DBMS coding over the last 15 years, with a boatload of
it on custom database packages that didn't do relational anything :-)

Frankly, the faster and further I can get away from the concept of a
row ID, the better I feel.

--
--
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly to FULL DS-3 Service
                 | NEW! K56Flex support on ALL modems
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost

Thus spake Karl Denninger
> Frankly, the faster and further I can get away from the concept of a
> row ID, the better I feel.

Row IDs are for spreadsheets, not databases.  :-)

--
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

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