[HACKERS] Behaviour of rows containg not-null domains in plpgsql

2008-02-24 Thread Florian G. Pflug
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

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

2008-02-24 Thread Andrew Dunstan
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

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

2008-02-24 Thread Florian G. Pflug
Andrew Dunstan wrote: Florian G. Pflug wrote: 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

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

2008-02-24 Thread Tom Lane
Florian G. Pflug [EMAIL PROTECTED] writes: I just stumbled over the following behaviour, introduced with 8.3, and wondered if this is by design or an oversight. No, this was in 8.2. If you define a domain over some existing type, constrain it to non-null values, and use that domain as a

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

2008-02-24 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: What seems worse is that it still fails even if you declare the domain to have a default value. Hmm, that seems like it could be a bug. We don't currently consider that a rowtype includes the parent table's defaults or constraints. But if we are going

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

2008-02-24 Thread Florian G. Pflug
Tom Lane wrote: Florian G. Pflug [EMAIL PROTECTED] writes: I just stumbled over the following behaviour, introduced with 8.3, and wondered if this is by design or an oversight. No, this was in 8.2. Ah, sorry - I'm porting an app from 8.1 straight to 8.3, and blindly assumes that i'd have

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

2008-02-24 Thread Tom Lane
Florian G. Pflug [EMAIL PROTECTED] writes: Plus, the fact that we don't support default specifications in pl/pgsql for row types turns this inconvenience into a major PITA, You mean initialization expressions, not defaults, correct? (I would consider the latter to mean that whatever attrdef

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

2008-02-24 Thread Florian G. Pflug
Tom Lane wrote: Florian G. Pflug [EMAIL PROTECTED] writes: Plus, the fact that we don't support default specifications in pl/pgsql for row types turns this inconvenience into a major PITA, You mean initialization expressions, not defaults, correct? (I would consider the latter to mean that