Re: GiST index on data types that require compression

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GiST index on data types that require compression
Дата
Msg-id 4914.990798446@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GiST index on data types that require compression  (Oleg Bartunov <oleg@sai.msu.su>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: PQsetdbLogin bug?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bug#98643: plpgsql SELECT INTO causes trouble when assignment impossible (fwd)