* Andrew Dunstan (andrew@dunslane.net) wrote:
> On 05/15/2013 10:27 AM, Tom Lane wrote:
> >You can certainly argue that it might be silly to have a local sequence
> >generating the default value for insertions into a remote table; but
> >on the other hand, it might not be silly, depending on usage scenario.
> >I don't think the database should be enforcing a policy choice like
> >that.
>
> Presumably if it's not appropriate they won't define it as a serial
> column. If Postgres is the primary source of the data rather than
> the foreign handler then it makes plenty of sense to have a serial
> column, I should think.
>
> So +1 for allowing it.
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.
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. I'm not suggesting that as
something we do for the user, but perhaps we could include a note along
these lines in the docs for users who need the default evaluated on the
remote? And come up with a better way to handle it in the future
(perhaps an option in the foreign table definition?). This, of course,
presumes that the solution I've described actually works, iow, not
tested. :)
Thanks,
Stephen
