Re: get_fn_expr_variadic considered harmful - Mailing list pgsql-hackers

From Tom Lane
Subject Re: get_fn_expr_variadic considered harmful
Date
Msg-id 13081.1396447589@sss.pgh.pa.us
Whole thread Raw
In response to Re: get_fn_expr_variadic considered harmful  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: get_fn_expr_variadic considered harmful
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 1, 2014 at 2:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> There's also the point that even if we changed ruleutils' behavior
>> now, this would not fix existing dump files that have considered the
>> two forms interchangeable ever since VARIADIC existed.  And we
>> generally try hard to not break existing dump files.  To be even
>> more to the point: what you propose is incapable of fixing the precise
>> problem stated in the bug report, because it's complaining about a
>> dump taken from 9.1, and there is *no* way to make 9.1 produce a
>> dump that only uses VARIADIC if the original call did.  It hasn't
>> got the information.  Even using a newer version of pg_dump wouldn't
>> help that.

> Well, that argues for the choice of trying to make them equivalent
> again, I suppose, but it sounds like there are some nasty edge cases
> that won't easily be filed down.  I think your idea of redefining
> funcvariadic to be true only for VARIADIC ANY is probably a promising
> approach to that solution, but as you say it leaves some problems
> unsolved.

I think what we'll have to do is tell complainants to recreate any
affected indexes or rules after installing 9.3.5.  Given the relatively
small number of complaints, I don't think it's worth working harder,
nor taking risks like inserting catalog lookups into readfuncs.c.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Including replication slot data in base backups
Next
From: Andrzej Mazurkiewicz
Date:
Subject: Re: Inheritance of foregn key constraints - dropping isinternal triggers by a