[SQL] Inheritance Semantics
Could someone (Chris Mead?) post an update on the status of fixing PostgreSQL's inheritance semantics in the following ways: Has a decision been made to implementing true inheritance via INHERITS or an alternative keyword? By true inheritance, I mean first and foremost that any query on a super-class should query *all members* of that class by default regardless of which table they are stored in. Any other behavior violates the very natural expectation that a table called "PERSON" actually implements the class of all persons. Second, for performance reasons, there needs to be a way for an index on a parent class attribute to be shared by all the tables that implement or inherit from that parent class. This is also necessary to enforce unique constraints on all members of a class. I imagine that the current implementation of "SELECT column FROM table*" is a logical UNION ALL of the select statement applied to each sub table, using different indexes for each one - Is this correct? Third, all declarative constraints on a parent class should be enforced against all members of all sub-classes without exception. Fourth, someday it would be nice to be able to create object methods & member functions that operate in the context of a single object. Does anyone know if the OQL supports this capability? I understand the backwards compatibility issue with the current semantics. Rather than adding some sort of run-time setting, I think it would be much better to add a new keyword / extension to the DDL syntax so that true ODMG style inheritance can be implemented correctly without breaking old applications. Any comments would be appreciated. - Mark Butler ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[SQL] Semantics of Typed Numeric Constants
Thomas Lockhart wrote in comp.databases.postgresql.hackers: > The parser does not know that your int4 constant "0" can be represented > as an int2. Try > > SELECT * FROM access_log WHERE method_num = int2 '0'; > > (note the type coersion on the constant; there are other ways of > specifying the same thing). Surely this is something that should be fixed. An int2 column ought to behave exactly like an int4 with a CHECK() constraint forcing the value to be in range. In object oriented terms: a smallint isA integer a integer isA bigint Likewise: a integer isA smallint if it falls in -32768..32767 a bigint isA integer if it falls in -2147483648..2147483647 Similar promotion rules should apply for all other numeric types. Any floating point value without a fractional part should be treated exactly like a big integer. The issues here are closely related to the 7.1 changes in INHERITS semantics. If any operator treats a smaller precision (more highly constrained) type in a materially different way than a compatible higher precision type, it is fundamentally broken for exactly the same reason that we expect a query on a super-class would be if if did not return all matching instances of every sub class. If a function is overloaded with multiple compatible scalar data types, the database should be free to call any matching implementation after performing an arbitrary number of *lossless* compatible type conversions. i.e. if you have f(smallint), f(integer), and f(double) the actual function called by f(0) should be undefined. The distinction between smallint '0', integer '0', and double '0' is meaningless and should be explicitly ignored. This is a little extreme, but I do not think it makes a lot of sense to maintain semantic differences between different representations of the same number. (Oracle certainly doesn't) Any comments? - Mark Butler ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
