Thread: typcategory for regconfig

Hi,

Does anyone know, why `typcategory` value for tsvector `regconfig` is
`TYPCATEGORY_NUMERIC`, but in all the tests it's being used in string format?
It's probably not a big deal, but in this thread [1] it prevents me from
adopting the nice solution with a boolean flag for `to_tsvector` function,
because Postgres can't distinguish between `to_tsvector(regconfig, text)` and
`to_tsvector(jsonb, boolean)` in the expression:

    to_tsvector('english', 'some text')

If it's value would be `TYPCATEGORY_STRING`, then everything will be fine,
since a string type will win. Also, it doesn't break any existing tests, so I
wonder whether it should be like that or not?

1:
https://www.postgresql.org/message-id/flat/CA%2Bq6zcXJQbS1b4kJ_HeAOoOc%3DunfnOrUEL%3DKGgE32QKDww7d8g%40mail.gmail.com

Dmitry Dolgov <9erthalion6@gmail.com> writes:
> Does anyone know, why `typcategory` value for tsvector `regconfig` is
> `TYPCATEGORY_NUMERIC`,

Because OID is.  I think we need all the OID-alias types to be the same
category as OID, else we're likely to have issues with queries like

    ... where oid = 'foo'::regwhatever

It's conceivable that we could move OID and all the reg* types into
their own category, but then the other time-honored locution of

    ... where oid = 25

would possibly give issues.

> It's probably not a big deal, but in this thread [1] it prevents me from
> adopting the nice solution with a boolean flag for `to_tsvector` function,
> because Postgres can't distinguish between `to_tsvector(regconfig, text)` and
> `to_tsvector(jsonb, boolean)` in the expression:

We are *not* putting these in category string.  They are not strings.
Furthermore, if we did so because

> ... then everything will be fine,
> since a string type will win.

then the odds are very good that these types would start to "win" some
other cases that we'd rather they didn't.

> Also, it doesn't break any existing tests

Doesn't prove a thing.  We do not have a suite of test cases exercising
whether the type resolution code will avoid doing the wrong thing.

I think you need to bite the bullet and just provide the flag in
the 3-argument case (regconfig,json[b],bool).

            regards, tom lane

> On 5 April 2018 at 15:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dmitry Dolgov <9erthalion6@gmail.com> writes:
>> Does anyone know, why `typcategory` value for tsvector `regconfig` is
>> `TYPCATEGORY_NUMERIC`,
>
> Because OID is.  I think we need all the OID-alias types to be the same
> category as OID, else we're likely to have issues with queries like

Ok, I see, thanks.

> I think you need to bite the bullet and just provide the flag in
> the 3-argument case (regconfig,json[b],bool).

Well, it's already like that. I have now:

    to_tsvector(json(b), boolean)
    to_tsvector(regconfig, json(b), boolean)

and as I mentioned above the first one is conflicting with
to_tsvector(regconfig, text).

Dmitry Dolgov <9erthalion6@gmail.com> writes:
> On 5 April 2018 at 15:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think you need to bite the bullet and just provide the flag in
>> the 3-argument case (regconfig,json[b],bool).

> Well, it's already like that. I have now:

>     to_tsvector(json(b), boolean)
>     to_tsvector(regconfig, json(b), boolean)

> and as I mentioned above the first one is conflicting with
> to_tsvector(regconfig, text).

Right.  So you need to either drop that form, or consider doing
something other than add-a-bool.  Maybe the alternate behavior
should have a different function name, instead of being selected
by an argument?

            regards, tom lane

> On 5 April 2018 at 15:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dmitry Dolgov <9erthalion6@gmail.com> writes:
>> On 5 April 2018 at 15:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I think you need to bite the bullet and just provide the flag in
>>> the 3-argument case (regconfig,json[b],bool).
>
>> Well, it's already like that. I have now:
>
>>     to_tsvector(json(b), boolean)
>>     to_tsvector(regconfig, json(b), boolean)
>
>> and as I mentioned above the first one is conflicting with
>> to_tsvector(regconfig, text).
>
> Right.  So you need to either drop that form, or consider doing
> something other than add-a-bool.  Maybe the alternate behavior
> should have a different function name, instead of being selected
> by an argument?

Yep, I'll swallow my perfectionism and go with a new function.

Dmitry Dolgov <9erthalion6@gmail.com> writes:
> On 5 April 2018 at 15:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Right.  So you need to either drop that form, or consider doing
>> something other than add-a-bool.  Maybe the alternate behavior
>> should have a different function name, instead of being selected
>> by an argument?

> Yep, I'll swallow my perfectionism and go with a new function.

There's plenty of nearby precedent for that, eg plainto_tsquery and
phraseto_tsquery, so I'm not even sure this is a less attractive option.

            regards, tom lane