From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Naming of new tsvector functions |
Date: | 2016-05-05 10:31:05 |
Message-ID: | 84e9008a-6d6f-c075-c6a8-fdba5f47349d@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/05/16 21:20, Stas Kelvich wrote:
>> On 04 May 2016, at 20:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> 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.
> 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, ts_rewrite)
> and two named starting from tsvector_* (tsvector_update_trigger, tsvector_update_trigger_column).
>
> Personally I’d prefer ts_ over tsvector_ since it is shorter, and still keeps semantics.
>
>> regards, tom lane
>
I've not been involved in doing any tsvector stuff, nor likely to in the
near future - but if i was, I think I'd find simpler to get into if
tsvector specific functions followed a common pattern of naming, like
Stas is suggesting.
Cheers,
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2016-05-05 10:50:09 | Re: atomic pin/unpin causing errors |
Previous Message | Dean Rasheed | 2016-05-05 10:24:31 | Re: More inaccurate results from numeric pow() |