Re: [BUGS] BUG #5053: domain constraints still leak

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #5053: domain constraints still leak
Date: 2009-09-15 10:44:03
Message-ID: 20090915104403.GB5407@samason.me.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Tue, Sep 15, 2009 at 05:13:21AM +0100, Andrew Gierth wrote:
> But there's a kicker: in Subclause 6.12, <cast specification>, in the
> General Rules is:
>
> a) If the <cast operand> specifies NULL, then the result of CS is
> the null value and no further General Rules of this Subclause
> are applied.
>
> That "no further General Rules" clause implies (assuming it's not a
> blatant mistake in the spec) that this rule is therefore skipped in
> the case of nulls:

I think the NOT NULL constraint is a PG specific constraint, I can't see
how it's allowed in the spec. Then again, I have trouble parsing the
spec so could well be wrong about this.

The NOT NULL constraint feels wrong as well, what are the semantics of:

CREATE DOMAIN d AS INTEGER NOT NULL;
SELECT a.n AS aa, b.n AS bb
FROM (VALUES (CAST(1 AS d)),(2)) a(n)
LEFT JOIN (VALUES (CAST(1 AS d))) b(n) ON a.n = b.n;

in the presence of it? I'm expecting aa and bb both to come out as
domain "d", but this shouldn't work with what you're saying the current
semantics should be.

--
Sam http://samason.me.uk/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2009-09-15 13:54:18 Re: [BUGS] BUG #5053: domain constraints still leak
Previous Message Sam Mason 2009-09-15 10:33:52 Re: [BUGS] BUG #5053: domain constraints still leak

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-09-15 10:49:02 Re: Streaming Replication patch for CommitFest 2009-09
Previous Message Sam Mason 2009-09-15 10:33:52 Re: [BUGS] BUG #5053: domain constraints still leak