I wrote: > There's a lot left to do here of course. One thing I was wondering > about was why we don't allow DEFAULTs to be attached to foreign-table > columns. There was no use in it before, but it seems sensible enough > now.
Hmm ... the buildfarm just rubbed my nose in a more immediate issue, which is that postgres_fdw is vulnerable to problems if the remote server is using different GUC settings than it is for things like timezone and datestyle. The failure seen here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rover_firefly&dt=2013-03-10%2018%3A30%3A00 is basically just cosmetic, but it's not hard to imagine non-cosmetic problems coming up. For instance, suppose our instance is running in DMY datestyle and transmits an ambiguous date to a remote running in MDY datestyle. We could consider sending our settings to the remote at connection establishment, but that doesn't seem terribly bulletproof --- what if someone does a local SET later? What seems safer is to set the remote to ISO style always, but then we have to figure out how to get the local timestamptz_out to emit that style without touching our local GUC. Ugh. (One more reason why GUCs that affect application-visible semantics are dangerous.) 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
