Re: [BUGS] BUG #5053: domain constraints still leak
От | Sam Mason |
---|---|
Тема | Re: [BUGS] BUG #5053: domain constraints still leak |
Дата | |
Msg-id | 20090915104403.GB5407@samason.me.uk обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #5053: domain constraints still leak (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: [BUGS] BUG #5053: domain constraints still leak
|
Список | 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/
В списке pgsql-hackers по дате отправления: