Re: GiST index on data types that require compression - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GiST index on data types that require compression
Date
Msg-id 4914.990798446@sss.pgh.pa.us
Whole thread Raw
In response to Re: GiST index on data types that require compression  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
Oleg Bartunov <oleg@sai.msu.su> writes:
> compress fully supports fixed-length and varlena types. The problem is
> index_formtuple - types of key and column could be different
> (example - polygon, where column has varlena type but key is fixed-length)

Right.  There used to be a horrible kluge whereby the user could specify
the type to be assumed for the key in the CREATE INDEX command (the
"haskeytype" stuff is the remaining traces of this).  This is brain dead
of course ... the correct way is to look at the pg_proc definition of
the compress function and see what type it's declared to return, not
rely on the user to get it right.

What I find just about as objectionable as the old haskeytype hack is
that the user has to tell you whether the index is lossy or not.  This
should be a property available from the system catalogs.  Not sure where
to put it; do we need another column in pg_opclass, or is someplace
other than the opclass needed?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: PQsetdbLogin bug?
Next
From: Tom Lane
Date:
Subject: Re: Bug#98643: plpgsql SELECT INTO causes trouble when assignment impossible (fwd)