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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers