Great, thanks. Yeah, I was thinking about that too--I am not sure if
there are any other examples of a time where Postgres deliberately
duplicates an argument like that (maybe there could be a check for it
to be a constexpr or something? But that information isn't available
at this point in the analysis process).
On Tue, Feb 18, 2014 at 9:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Joshua Yanovski <pythonesque@gmail.com> writes:
>> On Mon, Feb 17, 2014 at 4:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> While it would be a reasonably simple change to make this work as
>>> originally intended, I'm strongly tempted to just rip it out instead,
>>> and only support the SQL-mandated syntax. If anyone was using this
>>> undocumented feature, you'd think they'd have complained sometime in
>>> the last ten years. And making it work would really entail adding
>>> documentation and a regression test case, so it'd be substantially
>>> more effort than just killing the "list_length == 1" case.
>
>> Attaching a patch to just remove the n == 1 case.
>
> It occurred to me that there's an additional reason not to make the
> code work like Lockhart seems to have envisioned: if it did duplicate
> the argument like that, that'd lead to double evaluation of any volatile
> function that's present in the argument. So I've gone ahead and committed
> this, along with some further fooling around to make the error messages
> nicer.
>
> regards, tom lane
--
Josh
