Thread
-
Re: [QUESTIONS] Arrays (inserting and removing)
Marc G. Fournier <scrappy@hub.org> — 1998-01-14T13:17:50Z
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?
-
Re: [QUESTIONS] Arrays (inserting and removing)
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-01-14T14:44:18Z
> > 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 -
Re: [QUESTIONS] Arrays (inserting and removing)
Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-01-15T02:27:21Z
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
-
Re: [QUESTIONS] Arrays (inserting and removing)
Karl Denninger <karl@mcs.net> — 1998-01-15T15:34:14Z
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
-
Re: [QUESTIONS] Arrays (inserting and removing)
Marc G. Fournier <scrappy@hub.org> — 1998-01-15T15:40:43Z
> 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 :(
-
Re: [HACKERS] Re: [QUESTIONS] Arrays (inserting and removing)
D'Arcy Cain <darcy@druid.net> — 1998-01-15T18:33:40Z
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. -
Re: [HACKERS] Re: [QUESTIONS] Arrays (inserting and removing)
Marc G. Fournier <scrappy@hub.org> — 1998-01-15T18:42:51Z
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 :(
-
Re: [QUESTIONS] Arrays (inserting and removing)
Karl Denninger <karl@mcs.net> — 1998-01-15T20:32:20Z
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
-
Re: [HACKERS] Re: [QUESTIONS] Arrays (inserting and removing)
D'Arcy Cain <darcy@druid.net> — 1998-01-15T22:15:36Z
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. -
Re: [QUESTIONS] Arrays (inserting and removing)
Ralf Mattes <mattes@mhs.uni-freiburg.de> — 1998-01-15T22:58:22Z
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 ===========================================================================
-
Re: [HACKERS] Re: [QUESTIONS] Arrays (inserting and removing)
teunis <teunis@mauve.computersupportcentre.com> — 1998-01-17T06:56:27Z
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