Re: Column defaults for foreign tables (was Re: [v9.3] writable foreign tables)
Albe Laurenz <laurenz.albe@wien.gv.at>
From: Albe Laurenz <laurenz.albe@wien.gv.at>
To: "Tom Lane *EXTERN*" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Date: 2013-03-13T08:07:25Z
Lists: pgsql-hackers
Tom Lane wrote: > 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. That was my first thought on the topic, to have a solution that is simple (if not perfect). Your argument that it would be unpleasant to lose the ability to use sequence-generated remote default values made me reconsider. But there is a workaround, namely to use a trigger before insert to generate an automatic primary key (e.g. if the inserted value is NULL). Maybe it would be good to add a few hints at workarounds like that to the documentation if it's going to be local defaults. Yours, Laurenz Albe
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix postgres_fdw's issues with inconsistent interpretation of data values.
- cc3f281ffb0a 9.3.0 cited