Re: CREATE FOREIGN TABLE ( ... LIKE ... )

Поиск
Список
Период
Сортировка
От Vik Fearing
Тема Re: CREATE FOREIGN TABLE ( ... LIKE ... )
Дата
Msg-id 52D722D6.6000501@dalibo.com
обсуждение исходный текст
Ответ на Re: CREATE FOREIGN TABLE ( ... LIKE ... )  (Vik Fearing <vik.fearing@dalibo.com>)
Ответы Re: CREATE FOREIGN TABLE ( ... LIKE ... )  (David Fetter <david@fetter.org>)
Re: CREATE FOREIGN TABLE ( ... LIKE ... )  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 11/24/2013 02:03 AM, Vik Fearing wrote:
> On 10/15/2013 07:50 AM, David Fetter wrote:
>> On Mon, Oct 07, 2013 at 11:16:56PM -0700, David Fetter wrote:
>>> Folks,
>>>
>>> Please find attached a patch implementing and documenting, to some
>>> extent, $subject.  I did this in aid of being able to import SQL
>>> standard catalogs and other entities where a known example could
>>> provide a template for a foreign table.
>>>
>>> Should there be errhint()s, too?  Should we pile up all such errors
>>> and mention them at the end rather than simply bailing on the first
>>> one?
>>>
>>> TBD: regression tests.
>> Now included: regression tests for disallowed LIKE options.
> I like this patch, but I don't like its implementation at all.
>
> First of all, the documentation doesn't compile:
>
> openjade:ref/create_foreign_table.sgml:124:17:E: end tag for "LISTITEM"
> omitted, but OMITTAG NO was specified
> openjade:ref/create_foreign_table.sgml:119:4: start tag was here
>
>
> I fixed that, and then noticed that like_option is not explained like it
> is in CREATE TABLE.
>
> Then I got down to the description of the LIKE clause in both pages, and
> I noticed the last line of CREATE TABLE, which is "Inapplicable options
> (e.g., INCLUDING INDEXES from a view) are ignored.".  This is
> inconsistent with the behavior of this patch to throw errors for
> inapplicable options.
>
> Attached is a patch which corrects and completes the documentation
> issues noted above, and also silently ignores inapplicable options.  In
> addition to reducing patch size, this also allows the use of INCLUDING
> ALL.  Because these options no longer produce errors, and that's all the
> regression tests were looking for, I have removed those tests
> (unfortunately leaving none).
>
> Aside from this difference in behavior, I see no fault in this patch.
>
> I am marking this patch as 'returned with feedback' in the commitfest app.
>

It looks like this patch got left behind in the previous commitfest. 
What is the policy for moving it?  Is it too late and will have to wait
until the next commitfest?

https://commitfest.postgresql.org/action/patch_view?id=1254

-- 
Vik




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance