From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgres_fdw and defaults |
Date: | 2016-11-15 15:49:58 |
Message-ID: | 24303.1479224998@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I know we've discussed this before, but I have just had the unpleasant
> experience of trying to get around the difficulty of inserting into a
> foreign table with a serial field, surely a common enough scenario that
> we should try to deal with it better. The solution of using a local
> sequence really doesn't work, as there might be multiple users of the
> table, as there will be in my scenario. I opted instead to get a value
> from the foreign sequence explicitly before inserting, but that's pretty
> ugly. So I am wondering (without having looked at all closely at it) if
> we could set an option to tell the FDW that we want the foreign default
> to be used instead of a local one. Is the difficulty that we don't know
> if a value has been explicitly supplied or not? Maybe we could have some
> magic value that we could use instead ('foreign_default'?). I'm just
> throwing out ideas here, but this is really a wart that could well do
> with attention.
I'm not awake enough to recall the previous discussions of remote
default-value insertion in any detail, but they were extensive, and
no one has proposed solutions to the problems we hit. Please consult
the archives.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kuntal Ghosh | 2016-11-15 15:50:21 | Re: WAL consistency check facility |
Previous Message | Robert Haas | 2016-11-15 15:44:06 | Re: Parallel tuplesort (for parallel B-Tree index creation) |