Обсуждение: Triconsistent catalog declaration

On 09/15/2014 04:58 PM, Alexander Korotkov wrote:
> Hi!
>
> 9.4 GIN introduces new triconsistent method which can return one of three
> values in spite of just consistent method. But in catalog declaration
> triconsistent still returns bool type. It doesn't affect anything because
> nobody calls triconsistent from SQL.

Good point.

> But I think it would be correct to declare them returns int2.

No, int2 is two bytes wide, while the return value is a single byte. I 
guess "char" would be the right type.

That makes for a bit awkward input and output from psql, when the values 
used are 0, 1, 2, rather than ascii characters. But that's OK, because 
as you said these functions are not callable from psql anyway, as they 
have "internal" arguments.

This requires a catalog change to fix. Are we still planning to do a 
catversion bump for 9.4 because of the jsonb changes?

- Heikki

On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> That makes for a bit awkward input and output from psql, when the values
> used are 0, 1, 2, rather than ascii characters. But that's OK, because as
> you said these functions are not callable from psql anyway, as they have
> "internal" arguments.

Maybe we should change them to something a bit more understandable.

> This requires a catalog change to fix. Are we still planning to do a
> catversion bump for 9.4 because of the jsonb changes?

That was my understanding, although we seem to be proceeding at an
inexplicably glacial pace.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> This requires a catalog change to fix. Are we still planning to do a
>> catversion bump for 9.4 because of the jsonb changes?

> That was my understanding, although we seem to be proceeding at an
> inexplicably glacial pace.

We already had a post-beta2 catversion bump for 30c05261a.  As long
as this is a catalog fix and not an on-disk-data change, there's no
reason not to make it in 9.4.
        regards, tom lane

On 09/15/2014 08:56 PM, Robert Haas wrote:
> On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> That makes for a bit awkward input and output from psql, when the values
>> used are 0, 1, 2, rather than ascii characters. But that's OK, because as
>> you said these functions are not callable from psql anyway, as they have
>> "internal" arguments.
>
> Maybe we should change them to something a bit more understandable.

We can't change the return datatype to anything wider, or the values 
from 0, 1, 2, because those values have been chosen so that they are 
"compatible" with booleans. A boolean can be safely cast to a 
GinTernaryValue. I'm not sure if we make use of that anywhere ATM, but 
it's a useful property.

>> This requires a catalog change to fix. Are we still planning to do a
>> catversion bump for 9.4 because of the jsonb changes?
>
> That was my understanding, although we seem to be proceeding at an
> inexplicably glacial pace.

Ok, committed.

- Heikki