From: | Robert Treat <rob(at)xzilla(dot)net> |
---|---|
To: | Vick Khera <vivek(at)khera(dot)org> |
Cc: | David Pirotte <dpirotte(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Masquerading a unique index as a primary key in 8.4? |
Date: | 2011-11-08 16:46:29 |
Message-ID: | CABV9wwPDZ2k300Z9ckXe-EQy5tFgX9DH0E+8zjs_yGeXfC+rqA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Nov 8, 2011 at 11:28 AM, Vick Khera <vivek(at)khera(dot)org> wrote:
> On Tue, Oct 18, 2011 at 6:21 PM, David Pirotte <dpirotte(at)gmail(dot)com> wrote:
>> The underlying purpose is to get Londiste to acknowledge the table's key,
>> and this strategy seems to work without any problems. Londiste doesn't seem
>> to care that the "primary key" is only reflected in pg_index and isn't
>> accompanied by the relevant pg_constraint entry. Is modifying the
>> underlying pg_catalog tables like this "Very Bad"? Will it have mysterious
>> and unintended consequences, or can I get away with it? Thanks!
>
> The badness I see that will eventually come back to bite you is that
> your unique constraint is lacking "NOT NULL" and a PK by definition
> has NOT NULL. Therefore some other parts of the system is permitted
> to make that assumption, and when stuff fails because you lied to the
> system, you will probably never ever figure out or even know.
>
Agreed. I'd be more inclined to change londiste, or just ditch it for
something else that will recognize the unique index as a unique enough
identifier to enable replication. That limitation is kind of lame.
Robert Treat
conjecture: xzilla.net
consulting: omniti.com
From | Date | Subject | |
---|---|---|---|
Next Message | Vick Khera | 2011-11-08 16:56:17 | Re: Recommendations for SSDs in production? |
Previous Message | Rajesh Kumar Mallah | 2011-11-08 16:43:17 | Index Scan Backward on wrong index in partitioned table. |