Re: [PROPOSAL] Shared Ispell dictionaries

Поиск
Список
Период
Сортировка
От Arthur Zakirov
Тема Re: [PROPOSAL] Shared Ispell dictionaries
Дата
Msg-id CAKNkYnxG=zZq92=aFfuW=xFOiqh9VyBahJ2EfYFU4ZgR-S2Btw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PROPOSAL] Shared Ispell dictionaries  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
2018-01-24 20:57 GMT+03:00 Tomas Vondra <tomas.vondra@2ndquadrant.com>:
Thanks. I don't have time to review/test this before FOSDEM, but a
couple of comments regarding some of the points you mentioned.

Thank you for your thoughts.
 
> I thought about it. And it seems to me that we can use functions
> ts_unload() and ts_reload() instead of new syntax. We already have
> text search functions like ts_lexize() and ts_debug(), and it is
> better to keep consistency.

This argument seems a bit strange. Both ts_lexize() and ts_debug() are
operating on text values, and are meant to be executed as functions from
SQL - particularly ts_lexize(). It's hard to imagine this implemented as
DDL commands.

The unload/reload is something that operates on a database object
(dictionary), which already has create/drop/alter DDL. So it seems
somewhat natural to treat unload/reload as another DDL action.

Taken to an extreme, this argument would essentially mean we should not
have any DDL commands because we have SQL functions.

That being said, I'm not particularly attached to having this DDL now.
Implementing it seems straight-forward (particularly when we already
have the stuff implemented as functions), and some of the other open
questions seem more important to tackle now.

I understood your opinion. I haven't strong opinion on the subject yet.
And I agree that they can be implemented in future improvements for shared
dictionaries.

--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pgindent run?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: copy.c allocation constant