Thread: documentation updates for SQL:2023

SQL:2023 should be published within the next 2 months, so I want to 
update our SQL conformance information for our PostgreSQL release later 
this year.

Attached are patches that update the keywords list and the features list 
as usual.  (Some of the new features in the JSON area are still being 
worked on.  I have just set them all to NO for now, to be revisited later.)

I'm also proposing to get rid of the tracking of subfeatures.  This has 
been de-facto deprecated: All the subfeatures for optional features have 
been removed (replaced by top-level feature codes), and the subfeatures 
for mandatory features aren't very interesting.  The TODO is to remove 
the columns for the subfeatures in src/backend/catalog/sql_features.txt. 
  That is a mechanical change that I did not include in the patch.

I'll leave this patch set in the commit fest, to let those concurrent 
developments shake out and as a reminder to address this when the time 
comes.

On 01.03.23 10:12, Peter Eisentraut wrote:
> SQL:2023 should be published within the next 2 months, so I want to 
> update our SQL conformance information for our PostgreSQL release later 
> this year.
> 
> Attached are patches that update the keywords list and the features list 
> as usual.  (Some of the new features in the JSON area are still being 
> worked on.  I have just set them all to NO for now, to be revisited later.)

I have committed these patches.

> I'm also proposing to get rid of the tracking of subfeatures.  This has 
> been de-facto deprecated: All the subfeatures for optional features have 
> been removed (replaced by top-level feature codes), and the subfeatures 
> for mandatory features aren't very interesting.  The TODO is to remove 
> the columns for the subfeatures in src/backend/catalog/sql_features.txt. 
>   That is a mechanical change that I did not include in the patch.

I have dropped this for now.  This got a little bit more complicated 
than I had hoped, since the sql_features.txt file is also loaded into 
the information schema in initdb, and I didn't want to reorganize that 
right now.  Something to revisit some other time, perhaps.