Stephen Frost <sfr...@snowman.net> writes:
> I'm alright with allowing it and making it the 'default', but I can
> certainly see use-cases for having a sequence on the remote side which
> is used for new values for that table and I'd suggest that we figure out
> a way to support that.
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).
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.
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.
> At first blush, with 'simple' writable views, perhaps that can just be a
> view definition on the remote side which doesn't include that column and
> therefore that column won't be sent to the remote side explicitly but,
> but the view, running on the remote, would turn around and pick up the
> default value for any fields which aren't in the view definition when
> inserting into the table underneath.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
