Re: Data loss when '"json_populate_recorset" with long column name

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Денис Романенко <deromanenko(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Data loss when '"json_populate_recorset" with long column name
Date: 2021-09-07 14:08:30
Message-ID: 3169946.1631023710@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> On Tue, Sep 7, 2021 at 1:31 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> Yeah. We should try to work toward removing the limits on NAMEDATALEN
>> for the attribute names. Easier said than done :)

> Yes, but even if we eventually fix that my impression is that we would
> still enforce a limit of 128 characters (or bytes) as this is the SQL
> specification.

Probably not. I think SQL says that's the minimum expectation; and
even if they say it should be that exactly, there is no reason we'd
suddenly start slavishly obeying that part of the spec after ignoring
it for years ;-).

There would still be a limit of course, but it would stem from the max
tuple width in the associated catalog, so on the order of 7kB or so.
(Hmm ... perhaps it'd be wise to set a limit of say a couple of kB,
just so that the implementation limit is crisp rather than being
a little bit different in each catalog and each release.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2021-09-07 14:16:51 Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
Previous Message Tom Lane 2021-09-07 14:00:09 Re: [BUG?] SET TIME ZONE doesn't work with abbreviations