Nikita Glukhov <n.glu...@postgrespro.ru> writes: > [ 0001_recursive_json_populate_record_v02.patch ] > [ 0002_assign_ndims_to_record_function_result_types_v02.patch ]
I do not see the point of the second one of these, and it adds no test case showing why it would be needed. The example you quoted at the start of the thread doesn't fail for me in HEAD, so I surmise that it's falling foul of some assertion you added in the 0001 patch, but if so I think that assertion is wrong. attndims is really syntactic sugar only and doesn't affect anything meaningful semantically. Here is an example showing why it shouldn't: regression=# create table foo (d0 _int4, d1 int[], d2 int[3][4]); CREATE TABLE regression=# select attname,atttypid,attndims from pg_attribute where attrelid = 'foo'::regclass and attnum > 0; attname | atttypid | attndims ---------+----------+---------- d0 | 1007 | 0 d1 | 1007 | 1 d2 | 1007 | 2 (3 rows) Columns d0,d1,d2 are really all of the same type, and any code that treats d0 and d1 differently is certainly broken. So there should be no need to track a particular attndims for an output column of a function result, and in most cases it's not clear to me where you would get an attndims value from anyway. 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