Peter Eisentraut <peter_e@gmx.net> writes:
> Is there a reason why the conversion from CHAR to CHAR(1) is done in
> analyze.c:transformColumnType rather than right in the
> grammar?
Well, transformColumnType does database access, which is verboten during
the grammar phase. (The grammar has to execute correctly even if we're
in transaction-abort state, else we'll not be able to recognize the
COMMIT or ROLLBACK command...)
You could possibly do the equivalent work in the grammar based strictly
on recognizing the keywords CHAR, NUMERIC, etc, but I think that
approach will probably run into a dead end at some point. Really,
the grammar is NOT the place to be making semantic deductions. It
should give back an undecorated parse tree and let parse_analyze fill
in semantic deductions. (We've been pretty lax about that in the past,
but I've been trying to move semantics code out of gram.y recently.)
> peter=# select cast('voodoo' as char(1));
> ?column?
> ----------
> v
> (1 row)
> peter=# select cast('voodoo' as char);
> ?column?
> ----------
> voodoo
> (1 row)
Possibly transformColumnType() should be applied to datatype names
appearing in casts (and other places?) as well as those appearing in
table column declarations. However, I find your example unconvincing:
I'd expect the result of that cast to be of type char(6), not char(1).
In short, I don't believe the above-quoted behavior is wrong.
regards, tom lane
