Re: SQL/JSON features for v15

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, Amit Langote <amitlangote09(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Subject: Re: SQL/JSON features for v15
Date: 2022-08-30 14:33:45
Message-ID: f2f25b67-5283-f868-5396-20df05947a7b@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/30/22 9:16 AM, Andrew Dunstan wrote:
>
> On 2022-08-30 Tu 06:29, Amit Langote wrote:
>> On Tue, Aug 30, 2022 at 6:19 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>>> On 2022-Aug-30, Amit Langote wrote:
>>>
>>>> Patches 0001-0006:
>>>>
>>>> Yeah, these add the overhead of an extra function call (typin() ->
>>>> typin_opt_error()) in possibly very common paths. Other than
>>>> refactoring *all* places that call typin() to use the new API, the
>>>> only other option seems to be to leave the typin() functions alone and
>>>> duplicate their code in typin_opt_error() versions for all the types
>>>> that this patch cares about. Though maybe, that's not necessarily a
>>>> better compromise than accepting the extra function call overhead.
>>> I think another possibility is to create a static inline function in the
>>> corresponding .c module (say boolin_impl() in bool.c), which is called
>>> by both the opt_error variant as well as the regular one. This would
>>> avoid the duplicate code as well as the added function-call overhead.
>> +1
>>
>
> Makes plenty of sense, I'll try to come up with replacements for these
> forthwith.

The RMT had its weekly meeting today to discuss open items. As stated
last week, to keep the v15 release within a late Sept / early Oct
timeframe, we need to make a decision about the inclusion of SQL/JSON
this week.

First, we appreciate all of the effort and work that has gone into
incorporating community feedback into the patches. We did note that
folks working on this made a lot of progress over the past week.

The RMT still has a few concerns, summarized as:

1. There is not yet consensus on the current patch proposals as we
approach the end of the major release cycle
2. There is a lack of general feedback from folks who raised concerns
about the implementation

The RMT is still inclined to revert, but will give folks until Sep 1
0:00 AoE[1] to reach consensus on if SQL/JSON can be included in v15.
This matches up to Andrew's availability timeline for a revert, and
gives enough time to get through the buildfarm prior to the Beta 4
release[2].

After the deadline, if there is no consensus on how to proceed, the RMT
will request that the patches are reverted.

While noting that this RMT has no decision making over v16, in the event
of a revert we do hope this recent work can be the basis of the feature
in v16.

Again, we appreciate the efforts that have gone into addressing the
community feedback.

Sincerely,

John, Jonathan, Michael

[1] https://en.wikipedia.org/wiki/Anywhere_on_Earth
[2]
https://www.postgresql.org/message-id/9d251aec-cea2-bc1a-5ed8-46ef0bcf6c69@postgresql.org

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2022-08-30 14:36:49 Re: \pset xheader_width page as default? (Re: very long record lines in expanded psql output)
Previous Message Tom Lane 2022-08-30 14:28:52 Re: Convert *GetDatum() and DatumGet*() macros to inline functions