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

From Heikki Linnakangas
Subject Re: pg_restore multiple --function options
Date
Msg-id 521CFF8C.3000802@vmware.com
Whole thread Raw
In response to Re: pg_restore multiple --function options  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_restore multiple --function options  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_restore multiple --function options  (David Fetter <david@fetter.org>)
List pgsql-hackers
On 27.08.2013 21:56, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas@vmware.com>  writes:
>> 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.

Ok.

> 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.

Huh, what's that issue?

As the code stands, you have to pass the argument types to the 
--function flag, ie. --function="myfunc(integer)". It's annoyingly picky 
about the spelling, as the it has to match exactly what pg_dump prints, 
but it does handle selecting one function from a group of overloaded 
ones. And that really is orthogonal to whether or not you can give 
multiple --function arguments.

- Heikki



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Properly initialize negative/empty cache entries in relfilenodemap
Next
From: Hannu Krosing
Date:
Subject: Re: PL/pgSQL PERFORM with CTE