Re: [GENERAL] Proposed Changes to PostgreSQL

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