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
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 |