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
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 ? |