Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
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

Is this a documented inconsistency?

SQLFiddle here

share|improve this question

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:

share|improve this answer
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. – Jack Douglas May 17 '14 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 ... – Erwin Brandstetter May 17 '14 at 21:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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