Skip site navigation (1) Skip section navigation (2)

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

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Behaviour of rows containg not-null domains in plpgsql
Date: 2008-02-24 19:07:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> 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

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

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-02-24 19:16:13
Subject: Re: Behaviour of rows containg not-null domains in plpgsql
Previous:From: Joshua D. DrakeDate: 2008-02-24 18:24:35
Subject: Re: 8.3 / 8.2.6 restore comparison

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group