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
