Re: pg_restore multiple --function options

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: pg_restore multiple --function options
Date: 2013-08-27 18:56:54
Message-ID: 19656.1377629814@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 27.08.2013 03:26, Michael Paquier wrote:
>> On Tue, Aug 27, 2013 at 5:17 AM, David Fetter<david(at)fetter(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-08-27 18:56:58 Re: Properly initialize negative/empty cache entries in relfilenodemap
Previous Message Alvaro Herrera 2013-08-27 18:47:49 Re: error out when building pg_xlogdump with pgxs