Search Postgresql Archives

Re: Masquerading a unique index as a primary key in 8.4?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 8, 2011 at 11:28 AM, Vick Khera <vivek@xxxxxxxxx> wrote:
> On Tue, Oct 18, 2011 at 6:21 PM, David Pirotte <dpirotte@xxxxxxxxx> 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

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux