Re: A few questions about ltree

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Alban Hertroys <alban(at)magproductions(dot)nl>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: A few questions about ltree
Date: 2006-04-21 16:33:14
Message-ID: 20060421093132.Y16432@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 21 Apr 2006, Alban Hertroys wrote:

> Stephan Szabo wrote:
> >>SQL> CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
> >>ltree_test(path));
> >>NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> >>"ltree_test_pkey" for table "ltree_test"
> >>CREATE TABLE
> >>SQL> INSERT INTO ltree_test VALUES ('a'::ltree);
> >>INSERT 84117368 1
> >>SQL> INSERT INTO ltree_test VALUES ('a.b'::ltree);
> >>INSERT 84117369 1
> >>SQL> INSERT INTO ltree_test VALUES ('a.b.c'::ltree);
> >>INSERT 84117370 1
> >>SQL> DELETE FROM ltree_test WHERE path = 'a.b'::ltree;
> >>DELETE 1
> >
> > I'm not sure why you expect this to error. Any row that would reference
> > a.b would be removed by the delete AFAICS.
>
> Nope, there's no ON DELETE CASCADE on the FK, and RESTRICT is the
> default (thankfully).

The only row that matches 'a.b' that I see in the above is the second
insert which is also the row that is deleted in the delete. And since the
constraint uses equality, any row that matches path='a.b' is a target of
the delete because it's the same operator.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2006-04-21 17:46:13 Re: IDT timezone
Previous Message Teodor Sigaev 2006-04-21 16:25:08 Re: A few questions about ltree