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
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 |