Re: tsearch_core patch: permissions and security issues

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: tsearch_core patch: permissions and security issues
Дата
Msg-id 3490.1181918175@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: tsearch_core patch: permissions and security issues  ("Simon Riggs" <simon@2ndquadrant.com>)
Ответы Re: tsearch_core patch: permissions and security issues  ("Simon Riggs" <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: How does the tsearch configuration get selected?
Следующее
От: Michael Glaesemann
Дата:
Сообщение: Re: Change sort order on UUIDs?