Skip site navigation (1) Skip section navigation (2)

Re: Fix command completion for CREATE TABEL ... AS

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: (view raw, whole thread or download thread mbox)
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

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

Fernando Nasser
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 GrayDate: 2002-02-22 23:00:54
Subject: TOAST-slicing: substring access methods for TOASTed values.
Previous:From: Larry RosenmanDate: 2002-02-22 20:17:01
Subject: Re: IPv6 Support for INET/CIDR types.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group