Re: tsearch_core patch: permissions and security issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tsearch_core patch: permissions and security issues
Date
Msg-id 3490.1181918175@sss.pgh.pa.us
Whole thread Raw
In response to Re: tsearch_core patch: permissions and security issues  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: tsearch_core patch: permissions and security issues
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:
> Although I'm happy to see tsearch finally hit the big time, I'm a bit
> disappointed to see so many new datatype-specific SQL commands created.

Per subsequent discussion we are down to just one new set of commands,
CREATE/ALTER/DROP TEXT SEARCH CONFIGURATION, so it's not as big a
footprint as it was to start with.

> Can we consider CREATE TYPE CONFIGURATION with subsets such as...
> CREATE TYPE CONFIGURATION name USING FULLTEXT (map)
> CREATE TYPE CONFIGURATION name USING FULLTEXT (dictionary)
> CREATE TYPE CONFIGURATION name USING FULLTEXT (parser)

This seems entirely cosmetic, unless you have some proposal for allowing
a uniform underlying implementation not only syntax.  In the absence of
some concrete cases to consider, I don't see how we could imagine that
we know how to implement a useful generic approach.

I have been thinking that it would be smart to try to use the generic
"definition list" syntax, like CREATE OPERATOR and CREATE AGGREGATE.
But the motivation for that is just to avoid defining more keywords
(which has an overall impact on parser size and performance).  It's
not really going to do anything for us in terms of having an
implementation that can be shared with anything else.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: How does the tsearch configuration get selected?
Next
From: Michael Glaesemann
Date:
Subject: Re: Change sort order on UUIDs?