On Mon, Oct 30, 2017 at 5:52 PM, amul sul <sula...@gmail.com> wrote: > Actually, int4[] is also inappropriate type as we have started using a 64bit > hash function. We need something int8[] which is not available, so that I > have used ANYARRAYOID in the attached patch(0004).
I don't know why you think int8[] is not available. rhaas=# select 'int8[]'::regtype; regtype ---------- bigint[] (1 row) >> I wrote the following query >> to detect problems of this type, and I think we might want to just go >> ahead and add this to the regression test suite, verifying that it >> returns no rows: >> >> select oid::regprocedure, provariadic::regtype, proargtypes::regtype[] >> from pg_proc where provariadic != 0 >> and case proargtypes[array_length(proargtypes, 1)-1] >> when 2276 then 2276 -- any -> any >> when 2277 then 2283 -- anyarray -> anyelement >> else (select t.oid from pg_type t where t.typarray = >> proargtypes[array_length(proargtypes, 1)-1]) end >> != provariadic; >> > > Added in 0001 patch. Committed. > One advantage of current implementation is that we can see which hash > function are used for the each partitioning column and also we don't need to > worry about user specified opclass and different input types. > > Something similar I've tried in my initial patch version[1], but I have missed > user specified opclass handling for each partitioning column. Do you want me > to handle opclass using RelabelType node? I am afraid that, that would make > the \d+ output more horrible than the current one if non-default opclass used. Maybe we should just pass the OID of the partition (or both the partition and the parent, so we can get the lock ordering right?) instead. -- 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
