From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: inherit support for foreign tables |
Date: | 2014-01-31 18:05:08 |
Message-ID: | 20140131180508.GM2921@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I agree that using the FDW-specific options is the right approach and
> > disallowing those to be set on foreign tables makes sense. I don't
> > particularly like the idea of applying changes during inheiritance
> > which we wouldn't allow the user to do directly. While it might be a
> > no-op and no FDW might use it, it'd still be confusing.
>
> If we don't allow it directly, why not? Seems rather arbitrary.
I'm apparently missing something here. From my perspective, they're
either allowed or they're not and if they aren't allowed then they
shouldn't be allowed to happen. I'd view this like a CHECK constraint-
if it's a foreign table then it can't have a value for SET STORAGE. I
don't see why it would be 'ok' to allow it to be set if we're setting it
as part of inheiritance but otherwise not allow it to be set.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-01-31 18:15:05 | Re: pgindent wishlist item |
Previous Message | Andrew Dunstan | 2014-01-31 17:47:16 | Re: install libpq.dll in bin directory on Windows / Cygwin |