Using scalar function as set-returning: bug or feature? - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Using scalar function as set-returning: bug or feature?
Date
Msg-id 6c8775ab-4d73-7310-9283-eee06275f438@postgrespro.ru
Whole thread Raw
Responses Re: Using scalar function as set-returning: bug or feature?  (Sergei Kornilov <sk@zsrv.org>)
List pgsql-hackers
Hi hackers,

I wonder if the following behavior is considered to be a bug in plpgsql 
or it is expected result:

create table my_data(id serial primary key, time timestamp, type text);

create or replace function my_insert(type text) RETURNS BOOLEAN
AS
$BODY$
BEGIN
     insert into my_data (time, type) values (now(), type);
     return true;
END
$BODY$
LANGUAGE plpgsql;

create or replace function my_call_insert() RETURNS BOOLEAN
AS
$BODY$
DECLARE
   b boolean;
BEGIN
     select into b from my_insert('from func atx');
     return b;
END
$BODY$
LANGUAGE plpgsql;

select my_call_insert();
  my_call_insert
----------------

(1 row)

================================================

So, if function returning boolean is used in from list, then no error or 
warning is produced, but null value is assigned to the target variable.
If this code is rewritten in more natural way:

     b := my_insert('from func atx');
or
    select my_insert('from func atx') into b;

then function returns expected result (true).
I spent some time investigating this code under debugger and looks like 
the reason of the problem is that tuple descriptor for the row returned 
by my_insert() contains no columns (number of attributes is zero). May 
be there are some reasons for such behavior, but I find it quite 
confusing and unnatural. I prefer to report error in this case or return 
tuple with single column, containing return value of the function.

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning
Next
From: Masahiko Sawada
Date:
Subject: Re: Temporary tables prevent autovacuum, leading to XID wraparound