From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE FOREGIN TABLE LACUNA |
Date: | 2012-03-15 14:23:43 |
Message-ID: | 1331821220-sup-36@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
> On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
> > On Wed, Mar 14, 2012 at 10:22 AM, David Fetter <david(at)fetter(dot)org> wrote:
> > >> I think that instead of inventing new grammar productions and a new
> > >> node type for this, you should just reuse the existing productions for
> > >> LIKE clauses and then reject invalid options during parse analysis.
> > >
> > > OK. Should I first merge CREATE FOREIGN TABLE with CREATE TABLE and
> > > submit that as a separate patch?
> >
> > I don't see any reason to do that. I merely meant that you could
> > reuse TableLikeClause or maybe even TableElement in the grammer for
> > CreateForeignTableStmt.
>
> Next WIP patch attached implementing this via reusing TableLikeClause
> and refactoring transformTableLikeClause().
>
> What say?
Looks much better to me, but the use of strcmp() doesn't look good.
ISTM that stmtType is mostly used for error messages. I think you
should add some kind of identifier (such as the original parser Node)
into the CreateStmtContext so that you can do a IsA() test instead -- a
bit more invasive as a patch, but much cleaner.
Also the error messages need more work.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-03-15 14:34:22 | Re: Another review of URI for libpq, v7 submission |
Previous Message | Stuart Bishop | 2012-03-15 14:18:36 | Re: BUG #6532: pg_upgrade fails on Python stored procedures |