On 09/14/2017 11:11 AM, Rafal Pietrak wrote:
Not really.
As I said, I'm not looking for performance or "fair probability" of
planetary-wide uniqueness.
My main objective is the "guarantee". Which I've tried to indicate
referring to "future UPDATEs".
What I mean here is functionality similar to "primary key", or "unique
constraint". Whenever somebody (application, like faulty application
IMPORTANT!) tries to INSERT or UPDATE a not unique value there (which in
fact could possibly be generated earlier by UUID algorithms, or even a
sequence), if that value is among table that uses that (misterious)
"global primary key"; that application just fails the transaction like
any other "not unique" constraint failing.
That's the goal.
Multitude of tablas using a single sequence does not give that guarantee.
As I've said, a solution closest to my target is a separate table with
just one column of that "global primary key", which get inserted/updated
within trigger on insert/update of the "client tables" ... only I'm not
so sure how to "cleanly" manage multitude of tables using the same key
of that "global table of keys"... that is its "back references".
So I'm stuck with seriously incomplete solution.
that's why I have an impression, that I'm going into entirely wrong
direction here.
So you care if the same id is used in separate, unrelated tables? What's
your fear here? And I completely get the confusion generated be the
same small integer being re-used in various context ("sample id" is the
bane for me). Could you use a sufficiently accurate time value?
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
