Thanks for the comment. On 2018/04/10 21:11, Ashutosh Bapat wrote: > On Tue, Apr 10, 2018 at 5:32 PM, David Rowley > <david.row...@2ndquadrant.com> wrote: >> Apart from that confusion, looking at the patch: >> >> +CREATE OR REPLACE FUNCTION pp_hashint4_noop(int4, int8) RETURNS int8 AS >> +$$SELECT coalesce($1)::int8$$ LANGUAGE sql IMMUTABLE STRICT; >> +CREATE OPERATOR CLASS pp_test_int4_ops FOR TYPE int4 USING HASH AS >> +OPERATOR 1 = , FUNCTION 2 pp_hashint4_noop(int4, int8); >> +CREATE OR REPLACE FUNCTION pp_hashtext_length(text, int8) RETURNS int8 AS >> +$$SELECT length(coalesce($1))::int8$$ LANGUAGE sql IMMUTABLE STRICT; >> >> >> Why coalesce here? Maybe I've not thought of something, but coalesce >> only seems useful to me if there's > 1 argument. Plus the function is >> strict, so not sure it's really doing even if you added a default. > > I think Amit Langote wanted to write coalesce($1, $2), $2 being the > seed for hash function. See how hash operator class functions are > defined in sql/insert.sql.
Actually, I referenced functions and operator classes defined in hash_part.sql, not insert.sql. Although as you point out, I didn't think very hard about the significance of $2 passed to coalesce in those functions. I will fix that and add it back, along with some other changes that makes them almost identical with definitions in hash_part.sql. > May be we should just use the same > functions or even the same tables. Because hash_part.sql and partition_prune.sql tests run in parallel, I've decided to rename the functions, operator classes, and the tables in partition_prune.sql. It seems like a good idea in any case. Also, since the existing pruning tests were written with that table, I decided not to change that. Will post an updated patch after addressing David's comment. Regards, Amit