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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
