> On 04 May 2016, at 20:15, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Stas Kelvich <s.kelv...@postgrespro.ru> writes:
>>> On 04 May 2016, at 16:58, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> The other ones are not so problematic because they do not conflict with
>>> SQL keywords.  It's only delete() and filter() that scare me.
>> Okay, so changed functions to ts_setweight, ts_delete, ts_unnest, ts_filter.
> Somehow, I don't think you read what I wrote.
> Renaming the pre-existing setweight() function to ts_setweight() is
> not going to happen; it's been like that for half a dozen years now.
> It would make no sense to call the new variant ts_setweight() while
> keeping setweight() for the existing function, either.

Oh, I accidentally renamed one of the old functions, my mistake.

> I also don't see that much point in ts_unnest(), since unnest()
> in our implementation is a function not a keyword.  I don't have
> a strong opinion about that one, though.

Just to keep some level of uniformity in function names. But also i’m
not insisting.

> Also, I'd supposed that we'd rename to tsvector_something, since
> the same patch also introduced tsvector_to_array() and
> array_to_tsvector().  What's the motivation for using ts_ as the
> prefix?

There is already several functions named ts_* (ts_rank, ts_headline, 
and two named starting from tsvector_* (tsvector_update_trigger, 

Personally I’d prefer ts_ over tsvector_ since it is shorter, and still keeps 

>                       regards, tom lane

Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to