Hi,
Dimitri Fontaine writes:
> Can you test with this version and maybe better data set?
[...]
> Of course changing that will discard any btree containing a prefix_range
> column, so that's going to be 1.1.0 if workable.
http://github.com/dimitri/prefix
http://github.com/dimitri/prefix/comm
In article <87tywid19x@hi-media-techno.com>,
Dimitri Fontaine writes:
> The BTree opclass is not made to resist to overlapping data. Maybe in
> this case though we could say that 12 contains less elements than 1 so
> it's less than 1. Here's a test to redefine the pr_cmp() operator in
> term
Hi,
Bino Oetomo writes:
> ERROR: duplicate key value violates unique constraint "myrecords_pkey"
> CONTEXT: COPY myrecords, line 2: "12"
I think I should add the following code comment to the documentation, if
not already done:
/*
* We invent a prefix_range ordering for convenience, but that's
Dear Harald
Harald Fuchs wrote:
At least in prefix 1.0.0 unique indexes seem to be broken. Just drop
the primary key and add a separate index:
CREATE INDEX myrecords_record_ix ON myrecords USING gist (record);
Yup .. it works now.
Thankyou for your enlightment
Sincerely
-bino-
--
Sent
In article <4b0bbc8e.6010...@indoakses-online.com>,
Bino Oetomo writes:
> I downloaded pgfoundry's prefix, postgresql-8.3-prefix_1.0.0-1_i386.deb
> I install it using dpkg , and run the prefix.sql
> Create database .. named 'prefbino', and
> CREATE TABLE myrecords (
> record prefix_range NOT N
Dear All
Harald Fuchs wrote:
For larger tables where an index search would be useful, check out
pgfoundry.org/projects/prefix:
CREATE TABLE myrecords (
record prefix_range NOT NULL,
PRIMARY KEY (record)
);
COPY myrecords (record) FROM stdin;
1
12
123
1234
\.
I downloaded pgfoundry's p
