Stas Kelvich writes:
> On 06 May 2016, at 00:46, Gavin Flower wrote:
>> On 06/05/16 07:44, Tom Lane wrote:
>>> 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
> On 06 May 2016, at 00:46, Gavin Flower wrote:
>
> On 06/05/16 07:44, Tom Lane wrote:
>>
>> 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 tha
On 06/05/16 07:44, Tom Lane wrote:
Stas Kelvich writes:
On 04 May 2016, at 20:15, Tom Lane 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?
Th
Stas Kelvich writes:
>> On 04 May 2016, at 20:15, Tom Lane 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 severa
On 05/05/16 21:20, Stas Kelvich wrote:
On 04 May 2016, at 20:15, Tom Lane wrote:
Stas Kelvich writes:
On 04 May 2016, at 16:58, Tom Lane 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 chan
> On 04 May 2016, at 20:15, Tom Lane wrote:
>
> Stas Kelvich writes:
>>> On 04 May 2016, at 16:58, Tom Lane 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
Stas Kelvich writes:
>> On 04 May 2016, at 16:58, Tom Lane 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
> On 04 May 2016, at 16:58, Tom Lane wrote:
>
> Stas Kelvich writes:
>>> On 03 May 2016, at 00:59, David Fetter wrote:
>>> I suspect that steering that ship would be a good idea starting with
>>> deprecation of the old name in 9.6, etc. hs_filter(), perhaps?
>
>> In 9.5 there already were tsv
Stas Kelvich writes:
>> On 03 May 2016, at 00:59, David Fetter wrote:
>> I suspect that steering that ship would be a good idea starting with
>> deprecation of the old name in 9.6, etc. hs_filter(), perhaps?
> In 9.5 there already were tsvector functions length(), numnode(), strip()
> Recent c
> On 03 May 2016, at 00:59, David Fetter wrote:
>
> On Mon, May 02, 2016 at 01:58:11PM -0400, Tom Lane wrote:
>> I wrote:
>>> I think we'd be better off to rename these to tsvector_delete()
>>> and tsvector_filter() while we still can.
>>
>> ... although I now notice that hstore already exposes
On Mon, May 02, 2016 at 01:58:11PM -0400, Tom Lane wrote:
> I wrote:
> > I think we'd be better off to rename these to tsvector_delete()
> > and tsvector_filter() while we still can.
>
> ... although I now notice that hstore already exposes a function
> named delete(), so that ship may have sailed
On Mon, May 2, 2016 at 1:58 PM, Tom Lane wrote:
> I wrote:
>> I think we'd be better off to rename these to tsvector_delete() and
>> tsvector_filter() while we still can.
>
> ... although I now notice that hstore already exposes a function named
> delete(), so that ship may have sailed already. B
I wrote:
> I think we'd be better off to rename these to tsvector_delete() and
> tsvector_filter() while we still can.
... although I now notice that hstore already exposes a function named
delete(), so that ship may have sailed already. But I'm more troubled
by filter() anyhow, since that keywor
On 05/02/2016 10:27 AM, Tom Lane wrote:
I noticed that 6943a946c introduces some new functions named delete()
and filter(). This does not seem like a terribly bright idea to me.
They may not be formally ambiguous with the corresponding keywords,
but it's not very hard to imagine how small typos
I noticed that 6943a946c introduces some new functions named delete()
and filter(). This does not seem like a terribly bright idea to me.
They may not be formally ambiguous with the corresponding keywords,
but it's not very hard to imagine how small typos could lead to
the parser taking the uninte
15 matches
Mail list logo
