Re: postgres_fdw foreign tables and serial columns - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: postgres_fdw foreign tables and serial columns
Date
Msg-id 20130515151059.GO4361@tamriel.snowman.net
Whole thread Raw
In response to Re: postgres_fdw foreign tables and serial columns  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> The generic issue there is whether we can allow column defaults to be
> evaluated on the remote end.  The original postgres_fdw submission tried
> to support that, but it had enough bugs and logical inconsistencies that
> I ended up ripping that out before commit.  There's a good deal of
> discussion about that in the archives (in January or February IIRC).

Yeah, I watched much of that go by- just couldn't follow it entirely at
the time.  Still..

> However, when and if we do allow that to work, I'd still say that it's
> reasonable for "SERIAL" to mean local creation of the default value.

I agree with this; all I was trying to get at is that we shouldn't close
off any doors to eventually providing a way for defaults to be pushed to
the remote.

> If you want a remotely-supplied default to work, you'd not put a DEFAULT
> clause into the local definition; and SERIAL is essentially a shorthand
> for a DEFAULT clause.

Agreed.

> Yeah, I think the possibility of such a workaround was one of the
> reasons we decided it was okay to support only locally-computed
> defaults for now.

Right, and, of course, a simple trigger on the remote table would
probably work just fine too.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgres_fdw foreign tables and serial columns
Next
From: Heikki Linnakangas
Date:
Subject: Heap truncation without AccessExclusiveLock (9.4)