Re: Behaviour of rows containg not-null domains in plpgsql

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Behaviour of rows containg not-null domains in plpgsql
Дата
Msg-id 47C1A924.6000207@dunslane.net
обсуждение исходный текст
Ответ на Behaviour of rows containg not-null domains in plpgsql  ("Florian G. Pflug" <fgp@phlo.org>)
Ответы Re: Behaviour of rows containg not-null domains in plpgsql  ("Florian G. Pflug" <fgp@phlo.org>)
Re: Behaviour of rows containg not-null domains in plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

Florian G. Pflug wrote:
> Hi
>
> I just stumbled over the following behaviour, introduced with 8.3, and
> wondered if this is by design or an oversight.
>
> If you define a domain over some existing type, constrain it to
> non-null values, and use that domain as a field type in a table 
> definition, it seems to be impossible to declare pl/pgsql variables
> of that table's row type. The problem seems to be that upon declaration,
> the row variable is filled with nulls - but since the domain is marked
> not-null, that immediatly triggers an exception.
>
> Here is an example
> CREATE DOMAIN d AS varchar NOT NULL;
> CREATE TABLE t (txt d);
> CREATE FUNCTION f() RETURNS VOID AS $$
> DECLARE
>   v_t t;
> BEGIN
> END;
> $$ LANGUAGE 'plpgsql' VOLATILE;
> SELECT f();
>
> Note that the following works.
> CREATE TABLE t2 (txt varchar not null);
> CREATE FUNCTION f2() RETURNS VOID AS $$
> DECLARE
>   v_t t2;
> BEGIN
> END;
> $$ LANGUAGE 'plpgsql' VOLATILE;
> SELECT f2();
>
> If you guys agree that this is a bug, I'll try to find a fix and send 
> a patch.
>
>

What seems worse is that it still fails even if you declare the domain 
to have a default value.

cheers

andrew


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Florian G. Pflug"
Дата:
Сообщение: Behaviour of rows containg not-null domains in plpgsql
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 8.3 / 8.2.6 restore comparison