Re: pg_restore multiple --function options - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_restore multiple --function options
Date
Msg-id 19656.1377629814@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_restore multiple --function options  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: pg_restore multiple --function options  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 27.08.2013 03:26, Michael Paquier wrote:
>> On Tue, Aug 27, 2013 at 5:17 AM, David Fetter<david@fetter.org>  wrote:
>>> On Mon, Aug 26, 2013 at 10:29:06PM +0300, Heikki Linnakangas wrote:
>>>> While looking at the pg_restore code, I noticed that while it
>>>> supports specifying multiple --table options to restore several
>>>> tables, it does not support multiple --function options. Or --index,
>>>> --schema, or --trigger.
>>>> 
>>>> The support for multiple --table options was added in 9.3, in
>>>> January. See
http://www.postgresql.org/message-id/CAK3UJRG+yV1mK5twLfKVMCwXH4f6PnJou6Rn=ecabyfQH1vVHg@mail.gmail.com.
>>>> Was there a particular reason for only doing it for --table, or was
>>>> it just an oversight or lack of interest? No doubt that --table is
>>>> the most interesting one, but IMHO the other options should behave
>>>> the same, for the sake of consistency.

>>> +1 for making them consistent.  There will also be an improvement in
>>> usability.
>> +1. It would be good to have consistency there for all the objects.

> Would anyone object to backpatching that change to 9.3 ? The risk seems 
> very small, and it would be good to do the other options in the same 
> release as --table. It was an oversight to only do it for --table in 9.3.

> Assuming no objections, I'll apply the attached patch to 9.3 and master 
> later tonight.

I object, strongly.  This is a feature addition, and has no business going
in post-rc1, especially with no time for review.

As far as the function case goes, I'm not really thrilled about layering
more functionality on that until we've come to some understanding about
how to select from a group of overloaded functions.  It may be that this
is orthogonal to that issue ... or maybe not.  I don't have any objection
to fixing the non-function cases, as long as it's only in HEAD.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: error out when building pg_xlogdump with pgxs
Next
From: Alvaro Herrera
Date:
Subject: Re: Properly initialize negative/empty cache entries in relfilenodemap