Re: [GENERAL] Proposed Changes to PostgreSQL

From: Yury Don <yura(at)vpcit(dot)ru>
To: pgsql-general <pgsql-general(at)postgreSQL(dot)org>
Subject: Re: [GENERAL] Proposed Changes to PostgreSQL
Date: 2000-02-03 10:03:57
Message-ID: 3627.000203@vpcit.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-sql

Hello Chris,

Once, Thursday, February 03, 2000, 6:30:26 AM, you wrote:

CB> 1) An imaginary field in every tuple that tells you the class it came
CB> from.
CB> This is useful when you select from table* and want to know which
CB> relation the object actually came from. It wouldn't be stored on disk,
CB> and like oid it wouldn't be displayed when you do SELECT *. The field
CB> would be called classname. So you could have...
CB> SELECT p.classname, p.name FROM person p;
CB> person | Fred
CB> student | Bill
CB> employee | Jim
CB> person | Chris

I am voting for this by both hands. Now we forced to use an additional
column classname in every table and rule to fill this column.

CB> 2) Changing the sense of the default for getting inherited tuples.
CB> Currently you only get inherited tuples if you specify "tablename*".
CB> This would be changed so that you get all sub-class tuples too by
CB> default unless you specify "ONLY tablename". There are several
CB> rationale for this. Firstly this is what Illustra/Informix have
CB> implemented. Secondly, I believe it is more logical from an OO
CB> perspective as well as giving a more useful default. If a politician
CB> IS a person and I say SELECT * from person, then logically I should
CB> see all the politicians because they are people too (so they claim
CB> :). Thirdly, there are a whole range of SQL statements that should
CB> probably be disallowed without including sub-classes. e.g. an ALTER
CB> TABLE ADD COLUMN that does not include sub-classes is almost certainly
CB> undesirable. It seems ashame to have to resort to non-standard SQL
CB> with the "*" syntax in this case when it is really your only
CB> choice. Basicly, wanting ONLY a classname is a far more unusual
CB> choice, and leaving off the "*" is a common error. Fourthly, it seems
CB> out of character for the SQL language to have this single character
CB> operator. The SQL style is to use wordy descriptions of the operators
CB> meaning. "ONLY" fits well here because it describes its own meaning
CB> perfectly whereas to the unitiated, "*" is harder to guess at. While
CB> this change is an incompatibility I hope for those few people using
CB> inheritance they can accept the need to move forward without
CB> over-burden of backwards compatibility.

Sounds very logically.

--
Best regards,
Yury ICQ 11831432
mailto:yura(at)vpcit(dot)ru

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Hannu Krosing 2000-02-03 10:06:09 Re: [HACKERS] Re: [GENERAL] Proposed Changes to PostgreSQL
Previous Message Hannu Krosing 2000-02-03 10:00:20 Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-02-03 10:06:09 Re: [HACKERS] Re: [GENERAL] Proposed Changes to PostgreSQL
Previous Message Hannu Krosing 2000-02-03 10:00:20 Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

Browse pgsql-sql by date

  From Date Subject
Next Message Hannu Krosing 2000-02-03 10:06:09 Re: [HACKERS] Re: [GENERAL] Proposed Changes to PostgreSQL
Previous Message Hannu Krosing 2000-02-03 10:00:20 Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL