typcategory for regconfig

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