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

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 22:56:57
Message-ID: CAOBaU_ZAEDTKaDXyhs8ER8SCnE0-f7Q6H2hi6ytTfC8+VDr5tw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 7, 2021 at 10:08 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Julien Rouhaud <rjuju123(at)gmail(dot)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?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-09-08 00:34:14 Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)
Previous Message Tom Lane 2021-09-07 22:46:06 Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)