Re: DEFAULT of domain ignored in plpgsql (8.4.1)
От | Robert Haas |
---|---|
Тема | Re: DEFAULT of domain ignored in plpgsql (8.4.1) |
Дата | |
Msg-id | 603c8f070911200837wdad0aa2s165f4e5c7a93df02@mail.gmail.com обсуждение исходный текст |
Ответ на | DEFAULT of domain ignored in plpgsql (8.4.1) ("Florian G. Pflug" <fgp@phlo.org>) |
Ответы |
Re: DEFAULT of domain ignored in plpgsql (8.4.1)
|
Список | pgsql-hackers |
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug <fgp@phlo.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
В списке pgsql-hackers по дате отправления: