From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nikita Glukhov <n.gluhov@postgrespro.ru>
cc: Aleksander Alekseev <a.alekseev@postgrespro.ru>,
        Michael Paquier <michael.paquier@gmail.com>,
        PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: PATCH: recursive json_populate_record()
In-reply-to: <1b72a62e-fd94-fd6d-c573-870af0c8600d@postgrespro.ru>
References: <222c7cfb-73c8-a56e-7844-3dc51682760d@postgrespro.ru>
 <CAB7nPqR_su1w5yC2KMSuH=XmmY8JHL+aDz-sJzc3Ln-juOAgtQ@mail.gmail.com>
 <20161227131541.GA6976@e733.localdomain>
 <1b72a62e-fd94-fd6d-c573-870af0c8600d@postgrespro.ru>
Comments: In-reply-to Nikita Glukhov <n.gluhov@postgrespro.ru>
	message dated "Wed, 28 Dec 2016 03:13:56 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <11488.1483901523.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 08 Jan 2017 13:52:03 -0500
Message-ID: <11489.1483901523@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Nikita Glukhov <n.gluhov@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=3D# create table foo (d0 _int4, d1 int[], d2 int[3][4]);
CREATE TABLE
regression=3D# select attname,atttypid,attndims from pg_attribute where att=
relid =3D 'foo'::regclass and attnum > 0;
 attname | atttypid | attndims=20
---------+----------+----------
 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


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