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

From Julien Rouhaud
Subject Re: Data loss when '"json_populate_recorset" with long column name
Date
Msg-id CAOBaU_ZAEDTKaDXyhs8ER8SCnE0-f7Q6H2hi6ytTfC8+VDr5tw@mail.gmail.com
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 Tue, Sep 7, 2021 at 10:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Julien Rouhaud <rjuju123@gmail.com> writes:
>
> > 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;

Ah, I didn't know that.

> 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 ;-).

Well, yes but we ignored it for years due to technical limitation.
And the result of that is that we make migration to postgres harder.

If we somehow find a way to remove this limitation, ignoring the spec
again (assuming that the spec gives a hard limit) will make migration
from postgres harder and will also probably bring other problems
(allowing identifier kB long will lead to bigger caches for instances,
which can definitely bite hard).  Is it really worth it?



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)
Next
From: Fujii Masao
Date:
Subject: Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)