I think that the ONLY was wrong from day one :-(
Well, sure, but until we have an implementation that actually
*works* across multiple tables, it has to be there so that we
can at least consistently support the current single-table
semantics. Until we have some form of cross-table
Hi,
after starting this thread
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00222.php, I thought
I'd finally go for making foreign keys my own way instead of trying to patch
PostgreSQL. However, I've realized that managing foreign keys with my own
PL/SQL or C function isn't
On Jun 8, 2006, at 15:38 , Albert Cervera Areny wrote:
However, I've realized that managing foreign keys with my own
PL/SQL or C function isn't possible as I need DEFERRED checks which
are
currently only available for foreign keys.
I don't know enough about your situation to be sure if
The solution to the foreign key problem seems easy if I
modify PostgreSQL implementation and take off the ONLY word
from the SELECT query, but it's not an option for me, as I'm
I think that the ONLY was wrong from day one :-(
The default in other areas is table including childs.
(Not
Ühel kenal päeval, N, 2006-06-08 kell 08:38, kirjutas Albert Cervera
Areny:
Hi,
after starting this thread
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00222.php, I thought
I'd finally go for making foreign keys my own way instead of trying to patch
PostgreSQL. However,
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
The solution to the foreign key problem seems easy if I
modify PostgreSQL implementation and take off the ONLY word
from the SELECT query, but it's not an option for me, as I'm
I think that the ONLY was wrong from day one :-(
Well,
Tom Lane wrote:
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
The solution to the foreign key problem seems easy if I
modify PostgreSQL implementation and take off the ONLY word
from the SELECT query, but it's not an option for me, as I'm
I think that the ONLY was wrong from day
Andreas Pflug [EMAIL PROTECTED] writes:
I managed uniqueness using normal indexes and ins/upd triggers on all
child tables:
Do I need to point out the race-condition problems in this?
regards, tom lane
---(end of
