Re: [GENERAL] There can be only one

Create a partial unique index on is_default. Am 11. Oktober 2015 09:41:08 MESZ, schrieb Jason Dusek : >Consider a table of providers, for which one is the default. For >example, >payment providers: > >CREATE TABLE payment_via ( > iduuid PRIMARY KEY, > provider

Re: [GENERAL] There can be only one

Andreas Kretschmer wrote: > Create a partial unique index on is_default. as an example: test=# CREATE TABLE payment_via ( idint PRIMARY KEY, provider text NOT NULL, keys hstore NOT NULL DEFAULT '', is_defaultboolean NOT NULL

[GENERAL] There can be only one

Consider a table of providers, for which one is the default. For example, payment providers: CREATE TABLE payment_via ( iduuid PRIMARY KEY, provider text NOT NULL, keys hstore NOT NULL DEFAULT '' ); Here we store together the name of the provider — medici, paypal

Re: [GENERAL] There can be only one! How to avoid the highlander-problem.

Erwin Brandstetter [EMAIL PROTECTED] writes: I postulate further that a king only be king of his own people (rules out multiple kingships, too). That's not how it's worked in the past :) If you have a nation table wouldn't you just have a king_id column in that table which is a foreign key

Re: [GENERAL] There can be only one! How to avoid the highlander-problem.

On Jun 5, 8:35 am, [EMAIL PROTECTED] (Gregory Stark) wrote: Erwin Brandstetter [EMAIL PROTECTED] writes: I postulate further that a king only be king of his own people (rules out multiple kingships, too). That's not how it's worked in the past :) Yeah i know. :) That's why I had to

Re: [GENERAL] There can be only one! How to avoid the highlander-problem.

On Jun 5, 5:10 am, Lew [EMAIL PROTECTED] wrote: Erwin Brandstetter wrote: CREATE TABLE king ( king_id INTEGER PRIMARY KEY REFERENCES man (man_id) ON UPDATE CASCADE ON DELETE CASCADE, nation_id INTEGER UNIQUE, FOREIGN KEY (man_id, nation_id) REFERENCES man (man_id, nation_id)

Re: [GENERAL] There can be only one! How to avoid the highlander-problem.

Oh my, it took me a ton of text to finally come up with a better idea. 5.) The Sun King solution L'etat c'est moi!. The model is as simple as can be: CREATE TABLE nation ( nation_id SERIAL PRIMARY KEY ); CREATE TABLE man ( man_id SERIAL PRIMARY KEY, nation_id INTEGER NOT NULL REFERENCES

Re: [GENERAL] There can be only one! How to avoid the highlander-problem.

Hi Lew! Thank you for your comments. I have elaborated on them. On Jun 3, 7:22 pm, Lew [EMAIL PROTECTED] wrote: (...) The trouble with this is that it models kingship as an attribute of every man. (What, no female rulers allowed?) Yeah, saddening, isn't it? Actually, for simplicity's sake I

Re: [GENERAL] There can be only one! How to avoid the highlander-problem.

Erwin Brandstetter wrote: CREATE TABLE mankind ( man_id integer primary key, people_id integer NOT NULL, -- references table people .., but that's irrelevant here .. king boolean NOT NULL DEFAULT false ); The trouble with this is that it models kingship as an attribute of

Re: [GENERAL] There can be only one! How to avoid the highlander-problem.

On Jun 2, 2:43 am, [EMAIL PROTECTED] (Erwin Brandstetter) wrote: raise warning '%', kings; And remove this line of debug code. /Erwin ---(end of broadcast)--- TIP 6: explain analyze is your friend

[GENERAL] There can be only one! How to avoid the highlander-problem.

Hi group! In the course of trying to create a cleanly formated posting that would make my problem understandable I have eventually solved it myself. :) I now post the solution instead, maybe it is of interest to someone. :) Here is a showcase how to avoid to the highlander-problem. Imagine a

Re: [GENERAL] There can be only one! How to avoid the highlander-problem.

RETURN was missing in the AFTER triggers. here is the corrected version: - begin of code CREATE TABLE mankind ( man_id integer primary key, people_id integer NOT NULL, -- references table people .., but that's irrelevant here .. king boolean NOT NULL DEFAULT false );