Hi,
On Thu, May 4, 2023 at 3:58 AM Matthias Kurz wrote:
> On Wed, 3 May 2023 at 20:17, Alvaro Herrera wrote:
>> I would suggest to start a new thread with updated patches, and then a new
>> commitfest entry can be created with those.
>
> Whoever starts that new thread, please link link it here,
On Wed, 3 May 2023 at 20:17, Alvaro Herrera wrote:
>
> I would suggest to start a new thread with updated patches, and then a new
> commitfest entry can be created with those.
>
Whoever starts that new thread, please link link it here, I am keen to
follow it ;) Thanks a lot!
Thanks a lot for all
On 2023-May-03, Matthias Kurz wrote:
> On Wed, 5 Apr 2023 at 09:53, Alvaro Herrera wrote:
>
> > Okay, I've marked the CF entry as committed then.
>
> This was marked as commited in the 2023-03 commitfest, however there are
> still patches missing (for example the JSON_TABLE one).
> However, I c
On Wed, 5 Apr 2023 at 09:53, Alvaro Herrera wrote:
>
> Okay, I've marked the CF entry as committed then.
>
This was marked as commited in the 2023-03 commitfest, however there are
still patches missing (for example the JSON_TABLE one).
However, I can not see an entry in the current 2023-07 Commi
Hi,
IS JSON is documented as:
expression IS [ NOT ] JSON
[ { VALUE | SCALAR | ARRAY | OBJECT } ]
[ { WITH | WITHOUT } UNIQUE [ KEYS ] ]
which is fine but 'VALUE' is nowhere mentioned
(except in the commit-message as: IS JSON [VALUE] )
Unless I'm mistaken 'VALUE' does indeed not change an I
On 2023-Apr-04, Andrew Dunstan wrote:
> On 2023-04-04 Tu 08:36, Alvaro Herrera wrote:
> >
> > Surely this can be made cleaner.
> >
> > By the way -- that comment about clauses being non-standard, can you
> > spot exactly *which* clauses that comment applies to?
>
> Sadly, I don't think we're go
On 2023-04-04 Tu 08:36, Alvaro Herrera wrote:
Surely this can be made cleaner.
By the way -- that comment about clauses being non-standard, can you
spot exactly *which* clauses that comment applies to?
Sadly, I don't think we're going to be able to make further progress
before feature free
On 4/4/23 3:40 PM, Nikita Malakhov wrote:
Hi hackers!
The latest SQL standard contains dot notation for JSON. Are there any
plans to include it into Pg 16?
Or maybe we should start a separate thread for it?
I would recommend starting a new thread to discuss the dot notation.
Thanks,
Jonath
Hi hackers!
The latest SQL standard contains dot notation for JSON. Are there any plans
to include it into Pg 16?
Or maybe we should start a separate thread for it?
Thanks!
On Tue, Apr 4, 2023 at 3:36 PM Alvaro Herrera
wrote:
> On 2023-Apr-04, Amit Langote wrote:
>
> > On Tue, Apr 4, 2023 at
On 2023-Apr-04, Amit Langote wrote:
> On Tue, Apr 4, 2023 at 2:16 AM Alvaro Herrera wrote:
> > - the gram.y solution to the "ON ERROR/ON EMPTY" clauses is quite ugly.
> > I think we could make that stuff use something similar to
> > ConstraintAttributeSpec with an accompanying post-processin
Hi Alvaro,
On Tue, Apr 4, 2023 at 2:16 AM Alvaro Herrera wrote:
> On 2023-Mar-29, Alvaro Herrera wrote:
> > In the meantime, here's the next two patches of the series: IS JSON and
> > the "query" functions. I think this is as much as I can get done for
> > this release, so the last two pieces of
Hi Alvaro,
03.04.2023 20:16, Alvaro Herrera wrote:
So I pushed 0001 on Friday, and here are 0002 (which I intend to push
shortly, since it shouldn't be controversial) and the "JSON query
functions" patch as 0003. After looking at it some more, I think there
are some things that need to be addr
Here's v14 of the IS JSON predicate. I find no further problems here
and intend to get it pushed later today.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Siempre hay que alimentar a los dioses, aunque la tierra esté seca" (Orual)
>From 998ec6bd170e83cdb916ab
Hi,
29.03.2023 13:27, Alvaro Herrera wrote:
... and pushed it now, after some more meddling.
I'll rebase the rest of the series now.
Please look at the several minor issues/inconsistencies,
I've spotted in the commit:
1) s/JSON_ARRRAYAGG/JSON_ARRAYAGG/
2)
check_key_uniqueness vs check_uniqu
Op 3/29/23 om 12:27 schreef Alvaro Herrera:
On 2023-Mar-28, Erik Rijkers wrote:
In the json_arrayagg() description, it says:
'If ABSENT ON NULL is specified, any NULL values are omitted.'
That's true, but as omitting NULL values is the default (i.e., also without
that clause) maybe it's better
On 2023-Mar-28, Erik Rijkers wrote:
> In the json_arrayagg() description, it says:
> 'If ABSENT ON NULL is specified, any NULL values are omitted.'
> That's true, but as omitting NULL values is the default (i.e., also without
> that clause) maybe it's better to say:
> 'Any NULL values are omitted
Op 3/27/23 om 20:54 schreef Alvaro Herrera:
Docs amended as I threatened. Other than that, this has required more
> [v12-0001-SQL-JSON-constructors.patch]
> [v12-0001-delta-uniqueifyJsonbObject-bugfix.patch]
In doc/src/sgml/func.sgml, some minor stuff:
'which specify the data type returned'
On 27.03.23 20:54, Alvaro Herrera wrote:
Even so, I was unable to get bison
to accept the 'KEY name VALUES blah' syntax; it might be a
fun/challenging project to change the productions that we use for JSON
names and values:
+json_name_and_value:
+/* Supporting this syntax seems to require major
On Tue, Mar 28, 2023 at 6:18 AM Justin Pryzby wrote:
> I ran sqlsmith on this patch for a short while, and reduced one of its
> appalling queries to this:
>
> postgres=# SELECT jsonb_object_agg_unique_strict('', null::xid8);
> ERROR: unexpected jsonb type as object key
I think this may have to d
I ran sqlsmith on this patch for a short while, and reduced one of its
appalling queries to this:
postgres=# SELECT jsonb_object_agg_unique_strict('', null::xid8);
ERROR: unexpected jsonb type as object key
postgres=# \errverbose
ERROR: XX000: unexpected jsonb type as object key
UBICACIÓN: Js
On 08.03.23 22:40, Andrew Dunstan wrote:
There are probably some fairly easy opportunities to reduce the number
of non-terminals introduced here (e.g. I think json_aggregate_func could
possibly be expanded in place without introducing
json_object_aggregate_constructor and json_array_aggregate_c
On 2023-03-05 Su 22:18, Amit Langote wrote:
On Tue, Feb 28, 2023 at 8:36 PM Amit Langote wrote:
On Mon, Feb 27, 2023 at 4:45 PM Amit Langote wrote:
On Tue, Feb 21, 2023 at 2:25 AM Andres Freund wrote:
Evaluating N expressions for a json table isn't a good approach, both memory
and CPU eff
On Mon, Feb 27, 2023 at 4:45 PM Amit Langote wrote:
> On Tue, Feb 21, 2023 at 2:25 AM Andres Freund wrote:
> > Evaluating N expressions for a json table isn't a good approach, both memory
> > and CPU efficiency wise.
>
> Are you referring to JsonTableInitOpaque() initializing all these
> sub-expr
On Tue, Feb 21, 2023 at 12:09 PM Amit Langote wrote:
> On Mon, Feb 20, 2023 at 11:41 PM Erik Rijkers wrote:
> > Op 20-02-2023 om 08:35 schreef Amit Langote:
> > > Rebased again over queryjumble overhaul.
> > But the following statement is a problem. It does not crash but it goes
> > off, half-fre
Hi,
On 2023-02-20 16:35:52 +0900, Amit Langote wrote:
> Subject: [PATCH v4 03/10] SQL/JSON query functions
> +/*
> + * Evaluate a JSON error/empty behavior result.
> + */
> +static Datum
> +ExecEvalJsonBehavior(JsonBehavior *behavior, bool *is_null)
> +{
> + *is_null = false;
> +
> + switc
Op 20-02-2023 om 08:35 schreef Amit Langote:
Rebased again over queryjumble overhaul.
Hi,
But the following statement is a problem. It does not crash but it goes
off, half-freezing the machine, and only comes back after fanatic
Ctrl-C'ing.
select json_query(jsonb '[3,4]', '$[*]' retur
Hi Amit and Andrew,
Regarding not squashing [PATCH v3 11/11] Proposed reworking of
SQL/JSON documentaion, here is exactly what Tom Lane wrote in the comment to
commit 47046763c3:
Use
consistently for things that are in fact names of parameters (including
OUT parameters), reserving for
On Tue, 17 Jan 2023 at 19:01, Amit Langote wrote:
>
> On Wed, Dec 28, 2022 at 4:28 PM Amit Langote wrote:
> >
> > Hi,
> >
> > Rebased the SQL/JSON patches over the latest HEAD. I've decided to
> > keep the same division of code into individual commits as that
> > mentioned in the revert commit 2
On Wed, Jan 11, 2023 at 2:02 PM Elena Indrupskaya <
e.indrupsk...@postgrespro.ru> wrote:
>
> Sorry for upsetting your bot. :(
What I do in these cases is save the incremental patch as a .txt file --
that way people can read it, but the cf bot doesn't try to launch a CI run.
And if I forget that de
Tags in the patch follow the markup of the XMLTABLE function:
XMLTABLE (
XMLNAMESPACES (
namespace_uri AS
namespace_name , ... ),
row_expression
PASSING BY
{REF|VALUE}
document_expression
BY
{REF|VALUE}
COLUMNS name {
type PATH
column_expression
DEFAULT
default_expressio
On 2023-01-10 Tu 07:51, Elena Indrupskaya wrote:
> Hi,
>
> The Postgres Pro documentation team prepared another SQL/JSON
> documentation patch (attached), to apply on top of
> v1-0009-Documentation-for-SQL-JSON-features.patch.
> The new patch:
> - Fixes minor typos
> - Does some rewording agreed
Hi,
The Postgres Pro documentation team prepared another SQL/JSON
documentation patch (attached), to apply on top of
v1-0009-Documentation-for-SQL-JSON-features.patch.
The new patch:
- Fixes minor typos
- Does some rewording agreed with Nikita Glukhov
- Updates Docbook markup to make tags cons
On Wed, Dec 28, 2022 at 4:28 PM Amit Langote wrote:
>
> Hi,
>
> Rebased the SQL/JSON patches over the latest HEAD. I've decided to
> keep the same division of code into individual commits as that
> mentioned in the revert commit 2f2b18bd3f, squashing fixup commits in
> that list into the appropri
33 matches
Mail list logo
