Re: counterintuitive behaviour in pl/pgsql - Mailing list pgsql-general

From Dan S
Subject Re: counterintuitive behaviour in pl/pgsql
Date
Msg-id BANLkTim_Qne4nfAixVQYbTo9GMem2fkdow@mail.gmail.com
Whole thread Raw
In response to Re: counterintuitive behaviour in pl/pgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Yes throwing an error would probably be good to catch these kind of mistakes which silently gives you the wrong answer otherwise.

Best Regards
Dan S


2011/5/21 Tom Lane <tgl@sss.pgh.pa.us>
Dan S <strd911@gmail.com> writes:
> And yes I do know that I can fix the problem by renaming the output column
> to something else than i , I'm just curious about the behaviour and if it
> should work like this and why.

> CREATE OR REPLACE FUNCTION dynamic_query(i int) RETURNS TABLE (i int) as $$

This should probably throw an error.  There is a check that disallows
having two input or two output parameters named the same, but the
comment about it says:

           /*
            * As of Postgres 9.0 we disallow using the same name for two
            * input or two output function parameters.  Depending on the
            * function's language, conflicting input and output names might
            * be bad too, but we leave it to the PL to complain if so.
            */

It looks like plpgsql didn't get the memo about checking this.

                       regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: understanding pg_locks
Next
From: Pavel Stehule
Date:
Subject: Re: counterintuitive behaviour in pl/pgsql