From: | Fernando Nasser <fnasser(at)redhat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Fix command completion for CREATE TABEL ... AS |
Date: | 2002-02-22 21:44:27 |
Message-ID: | 3C76BBBB.AB445155@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
>
> Fernando Nasser <fnasser(at)redhat(dot)com> writes:
> > This patch fixes the response for a CREATE TABLE ... AS statement.
>
> 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.
> If your definition of "correct command tag" is "first word of what the
> user typed", we could get that more directly and reliably with a little
> bit of lexer hacking; we should not base it on the parse tree at all.
But the only thing that comes from yparse in the parsetree is a tag
(like
T_CreateAsStmt). I can't get hold of that token.
> But I'm not convinced that this is necessary or appropriate.
>
> On the other hand, maybe you've got some other goal in mind that makes
> it worthwhile to have distinct parse representations for SELECT ... INTO
> and CREATE ... AS. But please explain what the motivation is for
> changing this.
>
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.
As I implemented it with a minimal overhead it costs close to nothing
to get it right. So why not do it?
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From | Date | Subject | |
---|---|---|---|
Next Message | John Gray | 2002-02-22 23:00:54 | TOAST-slicing: substring access methods for TOASTed values. |
Previous Message | Larry Rosenman | 2002-02-22 20:17:01 | Re: IPv6 Support for INET/CIDR types. |