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

On Thu, Jan 16, 2014 at 01:07:50AM +0100, Vik Fearing wrote:
> 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

I think we should still be OK putting it in the current one.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate