Re: plpgsql: PERFORM vs. SELECT INTO (PERFORM not setting FOUND - Mailing list pgsql-sql

From Edmund Bacon
Subject Re: plpgsql: PERFORM vs. SELECT INTO (PERFORM not setting FOUND
Date
Msg-id 417D5D49.1090908@onesystem.com
Whole thread Raw
In response to plpgsql: PERFORM vs. SELECT INTO (PERFORM not setting FOUND variable?)  (Marinos Yannikos <mjy@geizhals.at>)
List pgsql-sql
Marinos Yannikos wrote:
> (btw.: I'm trying a few ways to ensure that all values in both t1 and t2 
> are unique:
> alter table blup add constraint check (blup_unique3(t1,t2));
>  - perhaps there are more elegant ways, any suggestions?)
>

No doubt someone will tell me this is Very Wrong:

create table blup_text(txt text primary key);

create table blup (t1 text references blup_text(txt),                   t2 text references blup_text(txt));

You may want to add NOT NULL conditions to t1, t2.

If your text values are long, this may be a good place to use synthetic 
keys - e.g.

create table blup_text(id serial primary key, txt text unique);
create table blup(t1 integer references blup_text(id),                  t2 integer references blub_text(id));



-- 
Edmund Bacon <ebacon@onesystem.com>


pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: plpgsql: PERFORM vs. SELECT INTO (PERFORM not setting FOUND variable?)
Next
From: jboes@nexcerpt.com (Jeff Boes)
Date:
Subject: How to recognize trigger-inserted rows?