Stephan Szabo wrote:
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> INSE
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> INS
Is it really necessary to insert an 'empty' record for the root node?
The 'a' record from my experiments seems to be quite suited for the
task, unless I'm missing something.
The root should be and it will be unremovable, because of foreign keys. But it
can be, of course, not empty.
alter
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> INSE
On Fri, 21 Apr 2006, Alban Hertroys wrote:
> Teodor Sigaev wrote:
> >> Maybe something along the lines of the following is possible?:
> >
> > Exact, it's for what ltree was developed.
>
> Cool, looks like it is what I need then.
>
> > contrib_regression=# select 'a.b.c' <@ 'a.b'::ltree;
> > ?colu
Teodor Sigaev wrote:
We've been experimenting with a table containing a branch 'a', 'a.b'
and 'a.b.c', but deleting 'a.b' didn't cause a constraint violation.
SQL> CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
ltree_test(path));
Sorry, only by using triggers on insert/delete/
We've been experimenting with a table containing a branch 'a', 'a.b' and
'a.b.c', but deleting 'a.b' didn't cause a constraint violation.
SQL> CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
ltree_test(path));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"ltree_t
Teodor Sigaev wrote:
Maybe something along the lines of the following is possible?:
Exact, it's for what ltree was developed.
Cool, looks like it is what I need then.
contrib_regression=# select 'a.b.c' <@ 'a.b'::ltree;
?column?
--
t
(1 row)
How would you use this to constrain a
That's the "classical" way, which is also used in our current
implementation with integers instead of ltrees, but it's not very easy
to query efficiently (at least ordering seems to remain a problem).
That (with integer ids) is classic way to support graph structure, ltree was
develop speciall
Yesterday ltree was mentioned to be a good system for tree structured
table data. I and a colleague of mine have been playing around with the
examples and the (rather sparse) documentation, but we're stuck on a few
questions...
How does one guarantee referential integrity using ltrees? It does
10 matches
Mail list logo
