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 worked with 8.2...
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.
What else would you expect it to do? AFAICS any other behavior would
be contrary to spec.
It's the inconsistency between row types (where the not-null contraint
in the table definition *doesn't* prevent a declaration like "myvar
mytable" in pl/pgsql), and domains (where the not-null constraint *does*
prevent such a declaration) that bugs me.
Plus, the fact that we don't support "default" specifications in
pl/pgsql for row types turns this inconvenience into a major PITA,
forcing you to use "record" when you know that correct type perfectly
well...
Is there some difficulty in implementing row-type defaults, or is it
just that nobody cared enough about them to do the work?
regards, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
