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: validating foreign tables |
Date: | 2011-02-22 03:40:31 |
Message-ID: | 17209.1298346031@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:
> On 02/21/2011 06:56 PM, Tom Lane wrote:
>> Huh? The options ought to be orthogonal to the table column info.
>> If they're not, maybe you need to rethink your option definitions.
> Well, let's take a couple of cases.
> 1. My old favorite, file as a text array.
> 2. A hypothetical RSS feed, where the options specify which RSS fields
> we want.
As above, I claim that an FDW that has such options is badly designed to
begin with. Why can't you generate the RSS command on-the-fly from the
table rowtype?
> Of course, we could just let these break or give odd results when we run
> a SELECT if the foreign table doesn't match what's expected. file_fdw
> will presumably break if the input file has rows with the wrong number
> of columns, just as COPY does. But there will be cases, like the two
> above, where a sanity check on the table shape could usefully be done at
> validation time as opposed to run time, and it would be nice to be able
> to do such a check.
I can't get excited about this. For one thing, you'd then need to worry
about involving the validator in random ALTER TABLE situations, not just
when changing the options it's supposed to be checking.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-22 03:45:01 | Re: validating foreign tables |
Previous Message | Andrew Dunstan | 2011-02-22 03:21:29 | Re: validating foreign tables |