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-05 19:44:36
Message-ID: 10331.1462477476@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 20:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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 Id prefer ts_ over tsvector_ since it is shorter, and still keeps semantics.

Yeah, I see we're already a bit inconsistent here. The problem with using
a ts_ prefix, to my mind, is that it offers no option for distinguishing
tsvector from tsquery, should you need to do that. Maybe this isn't a
problem for functions that have tsvector as input.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-05-05 19:56:45 Re: quickdie doing memory allocations (was atomic pin/unpin causing errors)
Previous Message Teodor Sigaev 2016-05-05 19:17:42 Re: atomic pin/unpin causing errors