I wrote: > Well, it would depend on how we fixed %TYPE, but my thought is that > we should teach the core parser to accept variable%TYPE anywhere that > a suitable "variable" is in scope. The core already allows related > syntaxes in some utility commands, but not within DML commands.
I poked at this a little bit, and concluded that it's probably impossible to do it exactly like that, at least not in a backward-compatible way. The difficulty is that TYPE is an unreserved keyword, and can therefore be a column name, while of course '%' is a valid operator. So for example SELECT x::int%type FROM ... currently means "cast column x to integer and then modulo it by column type". AFAICS there's no way to introduce %TYPE into the :: cast syntax without breaking this interpretation. I suppose that we could dodge this ambiguity by allowing %TYPE only in the CAST() notation, but this would be the first time that CAST and :: had any differences in how the type name could be spelled, and that's not a nice inconsistency to introduce either. What's possibly more palatable is to introduce some other special notation for "obtain the type of this expression at parse time". I'm thinking for example about SELECT x::pg_typeof(some_expression) FROM ... Maybe it would be too confusing to overload "pg_typeof" this way, in which case we could choose some other name. Aside from that consideration, this approach would have the effect of preventing "pg_typeof" from being used as an actual type name, or at least from being used as a type name that can have typmod, but that doesn't seem like a huge drawback. This way would have the rather nice property that some_expression could actually be any parseable expression, not merely a qualified variable name (which I think is the only case that we'd have had any hope of supporting with %TYPE). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers