"Tom Lane" <[EMAIL PROTECTED]> writes: > You could remove the immediate source of this objection if you could > redesign the APIs for the underlying support functions to be more > type-safe. I'm not sure how feasible or useful that would be though. > The bottom-line question here is whether developing a new parser or > dictionary implementation is really something that ordinary users might > do. If not, then having all this SQL-level support for setting up > catalog entries seems like wasted effort.
Well assuming we have any SQL-level support at all I think we should strive to avoid these functions taking INTERNAL arguments. I feel like having them in the GIST interface has been a major impediment to more people defining GIST indexes for more datatypes. Because you need to write C code dealing with internal data structures to handle page splits the bar to implement GIST index operator classes is too high for most users. So instead of a simple SQL command we end up with contrib modules implementing each type of GIST index. A while back I proposed that we implement the same page-split algorithm that most (or all?) of those contrib modules copy-paste between them as a default implementation. That would allow defining a GIST index in terms of a handful of operators like "distance" which could be defined with a type-safe api. This would be less flexible than the existing generic solution but it would allow defining new GIST indexes without writing C code. > But they still need some more thought about permissions, because AFAICS > mucking with a configuration can invalidate some other user's data. ouch. could mucking with a configuration create a corrupt index? This sounds sort of analogous to the issues collation bring up. > It seems to me that the single easiest and most useful part of a > configuration to change is the stop word list; but this setup guarantees > that no one but a DBA can do that, and what's more that pg_dump won't record > your changes. I would second that, in the past I was expected to provide an administrative web interface to adjust the list of stop words. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
