Re: Naming of new tsvector functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
Cc: David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Naming of new tsvector functions
Date: 2016-05-04 17:15:08
Message-ID: 12735.1462382108@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> writes:
>> On 04 May 2016, at 16:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

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.

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-05-04 17:31:18 Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Previous Message Andres Freund 2016-05-04 16:42:39 Re: what to revert