Re: Data loss when '"json_populate_recorset" with long column name - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Data loss when '"json_populate_recorset" with long column name
Date
Msg-id 3169946.1631023710@sss.pgh.pa.us
Whole thread Raw
In response to Re: Data loss when '"json_populate_recorset" with long column name  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Data loss when '"json_populate_recorset" with long column name  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Re: Data loss when '"json_populate_recorset" with long column name  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
Julien Rouhaud <rjuju123@gmail.com> writes:
> On Tue, Sep 7, 2021 at 1:31 PM Michael Paquier <michael@paquier.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



pgsql-hackers by date:

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