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
> 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
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?
Red Hat Canada Ltd. E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
In response to
pgsql-patches by date
|Next:||From: John Gray||Date: 2002-02-22 23:00:54|
|Subject: TOAST-slicing: substring access methods for TOASTed values.|
|Previous:||From: Larry Rosenman||Date: 2002-02-22 20:17:01|
|Subject: Re: IPv6 Support for INET/CIDR types.|