> 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, 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 -- 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: http://www.postgresql.org/mailpref/pgsql-hackers
