Re: BUG #19644: byteaout, float8out and float4out are marked IMMUTABLE but depend on GUCs

Hi,

hstore has the same problem. hstore(record) calls the output functions
of the record's column types, and populate_record(), which the #=
operator also uses, calls their input functions. But both are marked
IMMUTABLE, unlike the core functions that do the same, such as
row_to_json() and jsonb_populate_record(), which are STABLE. So they
are accepted in expression indexes and generated columns, although
their results depend on TimeZone, DateStyle, extra_float_digits and so
on. On master, as of e75fcc986:

CREATE EXTENSION hstore;
SET TimeZone = 'UTC';
CREATE TABLE ev (ts timestamptz);
CREATE INDEX ON ev ((hstore(ROW(ts)) -> 'f1'));
INSERT INTO ev VALUES ('2026-01-01 00:00+00');
SET TimeZone = 'Europe/Moscow';
SELECT count(*) FROM ev
WHERE hstore(ROW(ts)) -> 'f1' = '2026-01-01 03:00:00+03';
count
-------
0

The plan uses the index; with enable_indexscan and enable_bitmapscan
off, the same query returns 1. Likewise, a stored generated column
defined as (populate_record(NULL::rt, h)).ts, where rt is a composite
type with a timestamptz field, gets different values for the same h,
depending on the TimeZone at insert time.

It also leaves a way around e75fcc986: with x float8, ((x / 3)::text)
is now rejected in an index expression, but (hstore(ROW(x / 3)) -> 'f1')
is still accepted.

Both functions have been IMMUTABLE since they were added in 9.0. The
attached patch marks them STABLE, along the lines of the cube patch
upthread, bumps the hstore version to 1.9, and adds a test that such
indexes are rejected. Like the other changes here, I'd think this is
for master only.

I also checked core and the other contrib modules for IMMUTABLE
functions that call the I/O functions of arbitrary types, and found no
others.

--
Ilya Staroverov