From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | pg(at)heroku(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: subquery in CHECK constraint |
Date: | 2014-07-19 04:32:23 |
Message-ID: | 20140719.133223.1940636279314065748.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I think the basic problem would be what the check constraint subquery
> meant to the user, and how useful that is expected to be in general. A
> subquery in a check constraint would presumably involve checking the
> subquery using an existing snapshot of the command that required the
> constraint to be verified (say, an INSERT). But why should that
> snapshot be so special? In any case the result of the subquery may not
> be immutable (even in some limited, practical sense), and we expect
> check constraints to be on immutable conditions on constrained columns
> only. In general it would be practically impossible to determine that
> something else had changed the state of the database in such a way as
> to make the check constraint no longer verify successfully on each
> row, so we would not be able to prevent that from happening later on.
>
> I imagine that you have a very specific case in mind, though. Perhaps
> you can share the details.
No I don't have a specific case. I am just wondering because it's
defined in the standard.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | MauMau | 2014-07-19 06:59:21 | Re: [bug fix] Suppress "autovacuum: found orphan temp table" message |
Previous Message | Tom Lane | 2014-07-19 03:45:21 | Re: subquery in CHECK constraint |