| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: db_user_namespace a "temporary measure" |
| Date: | 2014-03-12 23:44:40 |
| Message-ID: | CA+TgmoZA8gz8-cOznh=3xd8uFB+qYGVC_b8ubQpaBwVNFxQgHw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> Isn't this just a case of creating a suitable operator and an exclusion
>> constraint? Defining the constraint in BKI might require extra
>> infrastructure, but it should be possible.
>
> Except that we don't have the infrastructure to perform such checks
> (neither partial, nor expression indexes, no exclusion constraints) on
> system tables atm. So it's not a entirely trivial thing to do.
I'm probably woefully underinformed here, but it seems like getting
exclusion constraints working might be simpler than partial indexes or
expression indexes, because both of those involve being able to
evaluate arbitrary predicates, whereas exclusion constraints just
involve invoking index access methods to look for conflicting rows via
smarts built into your index AM. The latter seems to involve less
risk of circularity (but I might be wrong).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thom Brown | 2014-03-12 23:52:55 | Re: Replication slots and footguns |
| Previous Message | Christian Kruse | 2014-03-12 23:36:37 | Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire |