Re: tsearch_core patch: permissions and security issues

"Tom Lane" <tgl@sss.pgh.pa.us> 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