On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> However ... one thing I was intending to mention on this thread is that >> "get the array type over this type" isn't the only extension one might >> wish for. Another likely desire is "get the type of field 'foo' of this >> composite type". I don't suggest that this patch needs to implement >> that right now; but it would be a good thing if we could see how the >> chosen syntax could be extended in such a direction. Otherwise we might >> be painting ourselves into a corner. > > To enlarge a little bit: it seems to me that what we're really wishing for > here is a type name syntax that goes beyond simple names. If we were > starting in a green field, we might choose a recursively-composable syntax > like the following. > > type_name can be: > > * A simple type name, such as int8 or varchar[42]. > > * TYPE_OF(expression), meaning that the SQL expression is parsed but never > executed, we just take this construct as naming its result type. > > * ARRAY_OF(type_name), meaning the array type having type_name as its > element type. > > * ELEMENT_OF(type_name), meaning the element type of the array type > named by type_name. > > * ROW_OF(type_name [, type_name ...]), meaning the composite type with > those types as columns. > > * FIELD_OF(type_name, foo), meaning the type of column "foo" of the > composite type named by type_name. I'm not sure if there would be > use-cases for selecting a column other than by a simple literal name, > but there could be variants of this function if so. > > It's possible to think of other cases, for example what about range > types? You could allow ELEMENT_OF() to apply to range types, certainly. > I'm not sure about the other direction, because multiple range types > could have the same element type; but it's possible to hope that some > type-naming function along the lines of RANGE_OF(type_name, other args) > could disambiguate. The main reason I'm thinking of a function-like > syntax here is that it can easily handle additional arguments when > needed. > > Comparing this flight of fancy to where we are today, we have > %TYPE as a remarkably ugly and limited implementation of TYPE_OF(), > and we have the precedent that foo[] means ARRAY_OF(foo). I'm not > sure how we get any extensibility out of either of those things. > > Or in short: maybe it's time to blow up %TYPE and start fresh.
That's not a dumb idea. I think %TYPE is an Oracle-ism, and it doesn't seem to have been their best-ever design decision. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
