Albe Laurenz <laurenz.albe@wien.gv.at> writes:
> Do you think that it is possible to insert remote defaults
> by omitting columns like this:
> INSERT INTO foreigntable (col1, col3) VALUES (a, c);
Well, that's how it works right now, but it's not good that it's
inconsistent with the explicit-DEFAULT case.
> If that can be made to work, then my opinion is that throwing an
> error on
> INSERT INTO foreigntable (col1, col2, col3) VALUES (a, DEFAULT, c);
> would be acceptable, because there is at least a workaround.
Aside from the oddness of not supporting that when it's equivalent
to the other case, what about this:
UPDATE foreigntable SET col2 = DEFAULT WHERE ...
There is no simple workaround if we don't provide support for that.
> If the first variant also cannot be made to work with remote
> defaults, then I'd say that the best is to use local
> defaults throughout and accept the loss of usability.
Yeah, I'm drifting towards the position that we should just define the
defaults as being whatever they are locally, rather than trying to be
cute about supporting remotely-executed defaults. It looks to me like
if we try to do the latter, we're going to have pitfalls and weird
corner cases that will never be quite transparent. There's also the
argument that this'd be a lot of work that benefits only some FDWs,
since the whole concept of remote column defaults doesn't apply when
the FDW's data source isn't a traditional RDBMS.
regards, tom lane
