Re: Fix command completion for CREATE TABEL ... AS - Mailing list pgsql-patches

Tom Lane wrote:
>
> 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.
>

No, it is an alias.  The same copy/equal are used.  Changes
are automatically carried over.  No maintenance required :-)


> 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?
>

No, those should print the SQL standard name.  The user must be aware
that he/she is using a non-standard name (extension) that is being
converted.   And the words mean the same thing, whereas CREATE and
SELECT are very different beasts.


> > 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.
>

The lexer does not know about statements.  What exactly do you mean?

And the parser does not return anything but the parsetree.  There we
could add one more parameter to yparse to return a command name.
I don't know how portable this meddling with yparse parameters is
though.


> 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.
>

I agree (see above) that extensions should return the standard
completion.

I have no problem with that.  I will be pleased to make SELECT...INTO
generate a CreateAsStmt and it will also print CREATE.


--
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9