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

From Gavin Flower
Subject Re: Data loss when '"json_populate_recorset" with long column name
Date
Msg-id 9a7e0beb-04c0-d164-af79-60bd4a60b357@archidevsys.co.nz
Whole thread Raw
In response to Re: Data loss when '"json_populate_recorset" with long column name  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 8/09/21 2:08 am, Tom Lane wrote:
> 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
>
>
How about 4kB (unless there are systems for which this is too large)?

That should be easy to remember.


Cheers,
Gavin




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: CI/windows docker vs "am a service" autodetection on windows
Next
From: Tom Lane
Date:
Subject: Re: Correct handling of blank/commented lines in PSQL interactive-mode history