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

Re: CREATE FOREGIN TABLE LACUNA

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE FOREGIN TABLE LACUNA
Date: 2012-03-14 14:27:28
Message-ID: 29988.1331735248@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Mar 14, 2012 at 8:28 AM, David Fetter <david(at)fetter(dot)org> wrote:
>> Here's a WIP patch (lots of cut/paste, no docs, no tests), but it does
>> work. Still to do in addition: decide whether ALTER FOREIGN TABLE
>> should also handle LIKE.

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

+1; in this approach, adding more features will make it worse not better.

> I'd actually like to see us allow foreign tables to have constraints.
> Obviously, we can't enforce constraints on remote data, but the point
> would be allow the system administrator to supply the query planner
> with enough knowledge to make constraint exclusion work.  The fact
> that you can't make that work today is a major gap, IMV.

Hm.  That opinion seems to me to connect to the recently-posted patch to
make contrib/file_fdw enforce NOT NULL constraints.  Should we instead
have the position that constraints declared for foreign tables are
statements that we can take on faith, and it's the user's fault if they
are wrong?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: David FetterDate: 2012-03-14 14:32:11
Subject: Re: CREATE FOREGIN TABLE LACUNA
Previous:From: David FetterDate: 2012-03-14 14:22:24
Subject: Re: CREATE FOREGIN TABLE LACUNA

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