Re: revision of todo: NULL for ROW variables - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: revision of todo: NULL for ROW variables
Date
Msg-id AANLkTi=JuLjYwz2JtwkPM+ZcMZpPQGwPfm2EZb5_+7er@mail.gmail.com
Whole thread Raw
In response to Re: revision of todo: NULL for ROW variables  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Mon, Nov 1, 2010 at 2:29 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Jeff Davis <pgsql@j-davis.com> wrote:
>
>> Seriously though, I think that we should stick as closely to the
>> letter of the standard as possible here (or, if there is
>> ambiguity, pick one reasonable interpretation). NULL semantics are
>> confusing enough without everyone making their own subtle tweaks.
>
> +1
>
> If the standard behavior doesn't support all the functionality we
> need, we should be looking at PostgreSQL extensions which do not
> conflict with standard syntax.  Supporting standard syntax with
> different semantics is evil.

I have basically two gripes with sql standard treatment of null row
values. One is the backward compatibility problem (which extends all
the way up to PQgetisnull, and would affect lots of my code) and the
other is that you will lose the ability to ever usefully enforce table
check constraints over rowtypes like we do for domains (you need to
reserve rowtype := null to skirt the issue in plpgsql declarations).

merlin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: why does plperl cache functions using just a bool for is_trigger
Next
From: Itagaki Takahiro
Date:
Subject: Re: Complier warnings on mingw gcc 4.5.0