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