Re: pg_restore multiple --function options
От | Heikki Linnakangas |
---|---|
Тема | Re: pg_restore multiple --function options |
Дата | |
Msg-id | 521CFF8C.3000802@vmware.com обсуждение исходный текст |
Ответ на | Re: pg_restore multiple --function options (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_restore multiple --function options
Re: pg_restore multiple --function options |
Список | 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 по дате отправления: