Fernando Nasser <fnasser@redhat.com> writes:
> Tom Lane wrote:
>> Do we really need the overhead of adding a new parse node type just
>> to change the command tag returned for a CREATE ... AS?
> There is not much overhead -- CreateAsStmt it is just an alias for
> SelectStmt.
Yes, but for every node type there need to be copy, compare, output,
and input routines; and something like SelectStmt is certain to need
changes from time to time, which will also have to get done on
CreateAsStmt (or cause subtle bugs if someone forgets). It's that
long-term maintenance cost that I'm objecting to.
Moreover, this is far from the only case where we translate multiple
user-entered constructs into the same parse-level representation.
A relevant example is that COMMIT and END produce identical parse
trees, as do ABORT and ROLLBACK. Will you insist on changing all
such cases?
> Well, getting a SELECT response for a CREATE statement is a little bit
> disconcerting (except for people that know that the old syntax used to
> be SELECT ... INTO). Doesn't look very professional.
Again, what's your definition of "looking professional"? Do you want to
define it as repeating the first word of what the user typed, regardless
of what our internal representation is? If so, I can make that happen,
in a direct way that doesn't depend on assuming any global properties
of the parse representation. A quick little hack to make the lexer save
the first lexed token of each statement will do nicely.
However, an equally defensible definition of "looking professional"
is "emitting the most standard name for the construct" --- this is
what we currently do with COMMIT/END/ABORT/ROLLBACK. I think it could
be argued with reasonable vigor that the right answer for your concern
is that SELECT...INTO and CREATE...AS should both produce
command-completion tags of CREATE.
regards, tom lane