Re: Documentation: GiST extension implementation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: Documentation: GiST extension implementation
Date: 2009-06-12 21:20:51
Message-ID: 24886.1244841651@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Le 12 juin 09 21:49, Tom Lane a crit :
>> It seems to me it could still do
>> with a lot more detail to specify what API the functions are really
>> expected to implement.

> I'm sorry I'm not following... I guess you're talking about a better
> high-level view of things? Like describing GiST itself, the way it's
> done in the following link, but reduced in one or two paragraphs?
> http://gist.cs.berkeley.edu/gist1.html

No, we already have that level of detail (some of it word for word in
fact); and it's not all that important for opclass authors to know how
GIST works anyway. What's bothering me is the fuzziness of the API
specifications for the support functions. It's not real clear for
example what you have to do to have an index storage type different from
the column datatype, and even less clear which type the same() function
is comparing. Having some skeletons that execute magic bits of
undocumented code is not a substitute for a specification.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-06-12 22:10:06 Re: machine-readable explain output
Previous Message Andrew Dunstan 2009-06-12 21:13:35 Re: machine-readable explain output