Re: Drawbacks of using BYTEA for PK? - Mailing list pgsql-general

From Chris Travers
Subject Re: Drawbacks of using BYTEA for PK?
Date
Msg-id 01d501c3d9d5$04686dc0$54285e3d@winxp
Whole thread Raw
In response to Drawbacks of using BYTEA for PK?  (David Garamond <lists@zara.6.isreserved.com>)
List pgsql-general
From: "John Sidney-Woollett" <johnsw@wardbrook.com>

>Careful...

> If two (or more) clients (in the same network) are going through a
> firewall that performs NAT, then they could appear to have the same IP
> address if the NAT address pool is small (single address).

Sorry, I should have been more specific about what I meant by "Unique
address."  The unique address is some identifier which can be reasonably
considered to be unique to the system md5(serial number of the first CPU ||
make/model of the CPU) or md5(mac address || ipv4 address) or ipv6 address.
Concatinating this with a timestamp and a sequence should provide very
little chance of a collision.

Here is a more interesting application though-- suppose you have a
distributed environment and want a way of transparently authenticating where
a record is supposed to be.  In this scenario, you have a situation where
you need some sort of GUID for the database server, which can be specified
when an addition is made or where the referring record exists.  If the
record exists in a different location the other child records could be
deflected there too (perhaps via dblink).  In this way, the pseudo-guid can
contain the customer number along with the location guid.  Any suggestions
on handling this in a manageable and opaque fashion (i.e. not giving
customers case numbers with the mac address fo the server appended ;-))

Best Wishes,
Chris Travers


pgsql-general by date:

Previous
From: "John Sidney-Woollett"
Date:
Subject: Nested transaction workaround?
Next
From: Anton.Nikiforov@loteco.ru
Date:
Subject: Re: insertion with trigger failed unexpectedly