David Fetter <da...@fetter.org> writes:
> On Wed, Dec 03, 2014 at 05:38:47PM -0500, Tom Lane wrote:
>> No. How would you know whether the remote side even has the enum,
>> let alone whether it has an identical set of members? I don't see
>> that enums are noticeably easier than the general case of
>> non-built-in types ...
> I must be missing something important. When querying the remote side,
> *and it's PostgreSQL*, we have catalog access that could be used to
> reconstruct the enums. Or are you thinking about the case where the
> enum changes from one call to the next?
What do you mean "reconstruct the enum"? We can't fix inconsistencies
between the local enum definition and the remote definition (if any).
Say the remote has a value x that we don't, it'll fail when SELECTing
a row containing that value; postgres_fdw has no way to prevent such
a failure. Conversely, if we have a value y that doesn't exist on the
remote side, transmitting a clause "enumcol = 'y'" to the remote side
would fail. postgres_fdw has no way to prevent that, either, save not
transmitting clauses involving enums (which is exactly what it does now).
I suppose we could say that if you create a foreign-table definition
that includes an enum-type column, it's on your head that the enum
exists and is compatibly defined on the far end. Not sure about the
risk-benefit tradeoff here though. If you get it wrong (example: the
two servers have different opinions about the sort order of the enum's
values), you would end up with *very* hard to debug wrong results.
I'm not convinced that we really want to encourage users to do that.
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
