Re: DEFAULT of domain ignored in plpgsql (8.4.1)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DEFAULT of domain ignored in plpgsql (8.4.1)
Date: 2009-11-20 16:37:40
Message-ID: 603c8f070911200837wdad0aa2s165f4e5c7a93df02@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug <fgp(at)phlo(dot)org> wrote:
> Hi
>
> It seems that pl/pgsql ignores the DEFAULT value of domains for local
> variables. With the following definitions in place
>
> create domain myint as int default 0;
> create or replace function myint() returns myint as $body$
> declare
>  v_result myint;
> begin
>  return v_result;
> end;
> $body$ language plpgsql immutable;
>
> issuing
> select myint();
> returns NULL, not 0 on postgres 8.4.1
>
> If the line
>  v_result myint;
> is changes to
>  v_result myint default 0;
> than 0 is returned as expected.
>
> I've tried to create a patch, but didn't see how I'd convert the result
> from get_typedefault() (A Node*, presumeably the parsetree corresponding
> to the default expression?) into a plan that I could store in a
> PLpgSQL_expr. I guess I'd need something like SPI_prepare_plan that
> takes a parse tree instead of a query string. Or am I on a completely
> wrong track there?
>
> While trying to cook up a patch I've also stumbled over what I perceive
> as a bug relating to DOMAINS and column DEFAULTs. I'll write that up in
> a second E-Mail to avoid confusion.

I suggest adding this to the open CommitFest (2010-01) at
https://commitfest.postgresql.org/action/commitfest_view/open

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-11-20 16:54:09 Prettification versus dump safety
Previous Message Ross J. Reedstrom 2009-11-20 16:36:23 Re: plruby code and postgres ?