Re: revision of todo: NULL for ROW variables

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: revision of todo: NULL for ROW variables
Date: 2010-11-01 23:07:56
Message-ID: AANLkTi=JuLjYwz2JtwkPM+ZcMZpPQGwPfm2EZb5_+7er@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 1, 2010 at 2:29 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2010-11-01 23:31:46 Re: Complier warnings on mingw gcc 4.5.0
Previous Message Tom Lane 2010-11-01 22:59:48 Re: why does plperl cache functions using just a bool for is_trigger