3
begin;
create table foo(id integer);
create function f1() returns void language sql as $$delete from foo;$$;
create function f2() returns void language plpgsql as $$begin delete from foo; end;$$;
select f1() is null, pg_typeof(f1()), f1()::text, f1()::text is null;
/*
 ?column? | pg_typeof | f1 | ?column?
----------+-----------+----+----------
 t        | void      |    | t            <----------------------the return is null
*/
select f2() is null, pg_typeof(f2()), f2()::text, f2()::text='';
/*
 ?column? | pg_typeof | f2 | ?column?
----------+-----------+----+----------
 f        | void      |    | t            <----------------------the return is not null
*/
rollback;

Is this a documented inconsistency?

SQLFiddle here

1 Answer 1

3

I don't believe it's documented. The behavior is incorrect or at best inconsistent but maintained probably because of a huge existing user code base that would break if it were corrected. The issue is caused by differences in how returns VOID is coded with SQL vs plpgsql. See: https://stackoverflow.com/questions/8319986/postgresql-functions-returning-void

2
  • thanks for the tremendously useful link. Not sure I agree about the 'huge existing user code base that would break': I think it's unlikely much code will be relying on the return from a void-returning function. May 17, 2014 at 20:54
  • @JackDouglas: Yeah, I still think this should be unified (or at least documented). Unifying the behavior might break some old code, but I, too, doubt that this has been used a lot. I never got around to report the bug. I probably should have ... May 17, 2014 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.