Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs
Date: 2015-01-07 02:42:44
Message-ID: 54AC9D24.9060506@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07-01-2015 AM 08:33, Jim Nasby wrote:
> On 1/6/15, 1:00 AM, Ashutosh Bapat wrote:
>>
>> Even checking whether the output of the function is in the right order
>> or not, has its cost. I am suggesting that we can eliminate this cost
>> as well. For example, PostgreSQL does not check whether a function is
>> really immutable or not.
>
> Actually, it does:
>
> select test();
> ERROR: UPDATE is not allowed in a non-volatile function
> CONTEXT: SQL statement "UPDATE i SET i=i+1"
> PL/pgSQL function test() line 3 at SQL statement
> STATEMENT: select test();
> ERROR: UPDATE is not allowed in a non-volatile function
> CONTEXT: SQL statement "UPDATE i SET i=i+1"
> PL/pgSQL function test() line 3 at SQL statement
>

I think Ashutosh's point is that there is no dedicated executor node to
perform this check. ISTM, the above error is raised during planning
itself as part of the initialization of state for a function.

Thanks,
Amit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-01-07 03:36:08 Re: pg_basebackup fails with long tablespace paths
Previous Message Jim Nasby 2015-01-07 02:37:56 Re: parallel mode and parallel contexts