On Jan 19, 2024, at 21:46, Erik Wienhold wrote:
> Interesting... copy-pasting the entire \set command works for me with
> psql 16.1 in gnome-terminal and tmux. Typing it out manually gives me
> the "unterminated quoted string" error. Maybe has to do with my stty
> settings.
Yes, same on macOS
On Jan 20, 2024, at 12:34, Tom Lane wrote:
> Surely we're not helping anybody by leaving that behavior in place.
> Making it do something useful, throwing an error, or returning NULL
> all seem superior to this. I observe that @@ returns NULL for the
> path type it doesn't like, so maybe that's
On Jan 20, 2024, at 11:45, Tom Lane wrote:
> You sure about that? It would surprise me if we could effectively use
> a not-equal condition with an index. If it is only == that works,
> then the preceding statement seems sufficient.
I’m not! I just assumed it in the same way creating an SQL = o
On Jan 20, 2024, at 12:34, Tom Lane wrote:
> It will take a predicate, but seems to always return true:
>
> regression=# select '{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] < 5' ;
> ?column?
> --
> t
> (1 row)
>
> regression=# select '{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] > 5' ;
> ?column?
>
On Jan 21, 2024, at 14:43, Tom Lane wrote:
> I don't entirely buy this argument --- if that is the interpretation,
> of what use are predicate check expressions? It seems to me that we
> have to consider them as being a shorthand notation for filter
> expressions, or else they simply do not make
On Jan 21, 2024, at 14:52, David E. Wheeler wrote:
> This is the only way the different behaviors make sense to me. @? expects a
> set, not a boolean, sees there is an item in the set, so returns true:
I make this interpretation based on this bit of the docs:
PostgreSQL's imp
On Jan 21, 2024, at 14:58, David E. Wheeler wrote:
> I make this interpretation based on this bit of the docs:
Sorry, that’s from my branch. Here it is in master:
A path expression can be a Boolean predicate, although the SQL/JSON
standard allows predicates only in filters. This
On Jan 24, 2024, at 16:32, Tom Lane wrote:
> "David E. Wheeler" writes:
>
>> In any event, something to do with @@, perhaps to have some compatibility
>> with `jsonb @> jsonb`? I don’t know why @@ was important to have.
>
> Yeah, that's certainly u
On Jan 25, 2024, at 11:03, Tom Lane wrote:
> I changed the preceding para to say "... check expressions are
> required in ...", which I thought was sufficient to cover that.
> Also, the tabular description of the operator tells you not to do it.
Yeah, that’s good. I was perhaps leaning into bein
Hackers,
I wanted to try to customize the subdirectory for an extension. The docs[1] say:
> directory (string)
>
> The directory containing the extension's SQL script file(s). Unless an
> absolute path is given, the name is relative to the installation's SHAREDIR
> directory. The default behav
On Jan 26, 2024, at 4:40 PM, David E. Wheeler wrote:
> But it doesn’t seem to work. I tried this experiment:
I made a simpler test case here:
https://github.com/theory/test-extension-directory
Not the difference between actual and expected output.
Best,
David
On Jan 26, 2024, at 5:05 PM, David E. Wheeler wrote:
> I made a simpler test case here:
>
> https://github.com/theory/test-extension-directory
>
> Not the difference between actual and expected output.
Bah! Need to also set `MODULEDIR = extension/click` and then it works.
D
Hey there, coming back to this. I poked at the logs in the master branch and
saw no mention of to_regtype; did I miss it?
On Sep 17, 2023, at 10:58 PM, David G. Johnston
wrote:
> Parses a string of text, extracts a potential type name from it, and
> translates that name into an OID. Failure
On Feb 2, 2024, at 3:23 PM, David G. Johnston
wrote:
> Seems like most just want to leave well enough alone and deal with the rare
> question for oddball input on the mailing list. If you are interested enough
> to come back after 4 months I'd suggest you write up and submit a patch. I'm
>
Hackers,
Attached is a patch to add a new function, `parse_type()`. It parses a type
string and returns a record with the typid and typmod for the type, or raises
an error if the type is invalid. It’s effectively a thin layer over the
parser’s parseTypeString() function.
The purpose of this fu
On Feb 4, 2024, at 13:02, Pavel Stehule wrote:
> I thinks so proposed functionality can be useful
Great, thank you!
Is that a review? :-)
D
On Feb 4, 2024, at 13:52, Pavel Stehule wrote:
> not yet, but I'll do it
Nice, thank you. I put it into the Commitfest.
https://commitfest.postgresql.org/47/4807/
Best,
David
On Feb 2, 2024, at 15:33, David E. Wheeler wrote:
> Anyway, I’m happy to submit a documentation patch along the lines you
> suggested.
How’s this?
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25460,11 +25460,12 @@ SELECT collation for ('foo' COLLATE "de_D
On Feb 4, 2024, at 19:11, Erik Wienhold wrote:
> Here "extracted names" should be "extracted name" (singular).
> Otherwise, the text looks good.
Ah, thank you. Updated patch attached.
Best,
David
v2-0001-Update-to_regtype-docs-regarding-error-condition.patch
Description: Binary data
On Feb 5, 2024, at 08:02, Jim Jones wrote:
> There are a few issues though:
Excellent, thank you very much! Updated patch attached.
Best,
David
v2-0001-Add-parse_type-SQL-function.patch
Description: Binary data
On Feb 5, 2024, at 09:49, Jim Jones wrote:
> Yes, if the function was strict (which in the current design is not the
> case) there is no need to check for nulls.
Right, done, and cleaned up the redundant comments.
Best,
David
v3-0001-Add-parse_type-SQL-function.patch
Description: Binary dat
On Feb 5, 2024, at 10:47 AM, Jim Jones wrote:
> The patch applies cleanly and it no longer crashes with NULL parameters.
> Docs render fine and regression tests pass. I have nothing more to add.
> Let's now wait for Pavel's review.
Much obliged!
D
Hackers,
The jsonpath doc[1] has an excellent description of the format of strings, but
for unquoted path keys, it simply says:
> Member accessor that returns an object member with the specified key. If the
> key name matches some named variable starting with $ or does not meet the
> JavaScrip
On Mar 16, 2024, at 14:39, David E. Wheeler wrote:
> I went looking for the JavaScript rules for an identifier and found this in
> the MDN docs[2]:
>
>> In JavaScript, identifiers can contain Unicode letters, $, _, and digits
>> (0-9), but may not start with a digit.
On Mar 17, 2024, at 15:12, Erik Wienhold wrote:
> Hi David,
Hey Erik. Thanks for the detailed reply and patch!
> So I think it makes sense to reword the entire backslash part of the
> paragraph and remove references to JSON entirely. The attached patch
> does that and also formats the backslas
On Mar 17, 2024, at 20:09, Erik Wienhold wrote:
>
> On 2024-03-17 20:50 +0100, David E. Wheeler wrote:
>> On Mar 17, 2024, at 15:12, Erik Wienhold wrote:
>>> So I think it makes sense to reword the entire backslash part of the
>>> paragraph and remove references t
On Mar 20, 2024, at 17:23, Tom Lane wrote:
> Pushed with some editorialization. Mostly, I whacked the
> documentation around pretty heavily: we have a convention for what
> examples in function descriptions should look like, and this wasn't
> it. Not entirely your fault, since some nearby entri
On Apr 1, 2024, at 06:55, walt...@technowledgy.de wrote:
> Also a configurable directoy to look up extensions, possibly even to be
> changed at run-time like [2]. The patch says this:
>
>> This directory is prepended to paths when loading extensions (control and
>> SQL files), and to the '$libd
Hackers,
In the Security lessons from liblzma thread[1], walther broached the subject of
an extension directory path[1]:
> Also a configurable directoy to look up extensions, possibly even to be
> changed at run-time like [2]. The patch says this:
>
>> This directory is prepended to paths when
On Apr 3, 2024, at 3:57 AM, walt...@technowledgy.de wrote:
> I can also imagine that it would be very helpful in a container setup to be
> able to set an environment variable with this path instead of having to
> recompile all of postgres to change it.
Yes, I like the suggestion to make it requ
On Apr 3, 2024, at 8:54 AM, David E. Wheeler wrote:
> Yes, I like the suggestion to make it require a restart, which lets the
> sysadmin control it and not limited to whatever the person who compiled it
> thought would make sense.
Or SIGHUP?
D
On Apr 3, 2024, at 8:54 AM, David E. Wheeler wrote:
> Yes, I like the suggestion to make it require a restart, which lets the
> sysadmin control it and not limited to whatever the person who compiled it
> thought would make sense.
Here’s a revision of the Debian patch that requires
On Apr 3, 2024, at 12:46 PM, Christoph Berg wrote:
> Thanks for bringing this up, I should have submitted this years ago.
> (The patch is originally from September 2020.)
That’s okay, it’s still 2020 in some ways. 😂
> I designed the patch to require a superuser to set it, so it doesn't
> matter
Hello Hackers,
A question about the behavior of the JSON Path parser. The docs[1] have this to
say about numbers:
> Numeric literals in SQL/JSON path expressions follow JavaScript rules, which
> are different from both SQL and JSON in some minor details. For example,
> SQL/JSON path allows .1
On Apr 7, 2024, at 15:46, Erik Wienhold wrote:
> I guess jsonpath assumes that hex, octal, and binary literals are
> integers. So there's no ambiguity about any fractional part that might
> follow.
Yeah, that’s what the comment in the flex file says:
https://github.com/postgres/postgres/blob/b
On Apr 10, 2024, at 10:29, Peter Eisentraut wrote:
> So the whole thing is
>
>
>
> The syntax of and is then punted to
> ECMAScript 5.1.
>
> 0x2 is a HexIntegerLiteral. (There can be no dots in that.)
>
> p10 is an Identifier.
>
> So I think this is all correct.
That makes sense, tha
On Feb 10, 2024, at 20:52, Erik Wienhold wrote:
>
> Let me comment on some issues since I wrote the very first version of
> parse_type() on which David's patch is based.
Thanks Erik.
>> On 2024-02-01 01:00 +0100, jian he wrote:
>> if you are wondering around other code deal with NULL, ErrorSav
On Feb 12, 2024, at 12:53 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> [ v4-0001-Add-parse_type-SQL-function.patch ]
>
> It strikes me that this is basically to_regtype() with the additional
> option to return the typmod. That leads to some questions:
Huh.
On Feb 12, 2024, at 15:55, David E. Wheeler wrote:
> Happy to move it wherever makes the most sense.
Update with a bunch of the suggested changes. Some questions still open from
the previous post, though.
Best,
David
v5-0001-Add-parse_type-SQL-function.patch
Description: Binary data
On Feb 18, 2024, at 15:55, Erik Wienhold wrote:
>> The overhead of parse_type_and_format can be related to higher planning
>> time. PL/pgSQL can assign composite without usage FROM clause.
>
> Thanks, didn't know that this makes a difference. In that case both
> variants are on par.
Presumably
On Feb 19, 2024, at 15:47, Tom Lane wrote:
>> 1. Add a to_regtypmod() for those who just want the typemod.
>
> Seems like there's a good case for doing that.
I’ll work on that.
> I'm less thrilled about that, mainly because I can't think of
> a good name for it ("format_type_string" is certain
On Feb 19, 2024, at 21:58, Erik Wienhold wrote:
> See the patch I wrote for my benchmarks. But it's pretty easy anyway to
> cut down parse_type() ;)
LOL, I missed that, just wrote it myself in the last hour. :-) v6 attached.
> But you don't actually need reformat_type() in pgTAP. You can just
On Feb 20, 2024, at 01:30, jian he wrote:
> the second hint `-- grammar error expected` seems to contradict with
> the results?
Quite right, thank you, that’s actually a trapped error. I’ve tweaked the
comments and their order in v7, attached.
This goes back to the discussion of the error rais
On Feb 5, 2024, at 09:01, David E. Wheeler wrote:
> Ah, thank you. Updated patch attached.
I’ve moved this patch into the to_regtype patch thread[1], since it exhibits
the same behavior.
Best,
David
[1]
https://www.postgresql.org/message-id/60ef4e11-bc1c-4034-b37b-695662
On Feb 20, 2024, at 21:09, Erik Wienhold wrote:
> The references are printed as "???" right now. Can be fixed with
> xreflabel="format_type" and xreflabel="to_regtype" on those
> elements.
Thanks.
> The docs show parameter name "type" but pg_proc.data does not define
> proargnames. So the to
On Feb 21, 2024, at 11:18, Erik Wienhold wrote:
> Thanks. But it's an applefile again, not a patch :P
WTF. I still have that feature disabled.
Oh, I think I deleted the file after dragged it into Mail but before sending,
because it’s empty everywhere I look. 🤦🏻♂️ Let’s try that again.
Best,
On Feb 21, 2024, at 11:54 AM, David Wheeler wrote:
> Merged this change into the [to_regtypemod
> patch](https://commitfest.postgresql.org/47/4807/), which has exactly the
> same issue.
>
> The new status of this patch is: Needs review
Bah, withdrawn.
D
On Feb 21, 2024, at 16:43, Erik Wienhold wrote:
> The docs still state that to_regtypemod() has a named parameter, which
> is not the case per pg_proc.dat.
Bah, I cleaned it up before but somehow put it back. Thanks for the catch.
Fixed.
Best,
David
v9-0001-Add-to_regtypemod-SQL-function.p
On Feb 21, 2024, at 17:19, Erik Wienhold wrote:
> Thanks David! LGTM.
Thanks. Anyone else? Or is it ready for committer?
Best,
David
On Feb 21, 2024, at 19:13, David E. Wheeler wrote:
> Thanks. Anyone else? Or is it ready for committer?
What’s the protocol for marking a patch ready for committer?
Thanks,
David
On Feb 24, 2024, at 19:11, Jim Jones wrote:
>> What’s the protocol for marking a patch ready for committer?
>
> I guess after the review of the last assigned reviewer
Oh, I didn’t realize someone was assigned. :-)
> The fact that a completely invalid type returns NULL ..
>
> SELECT to_regtype
On Feb 28, 2024, at 1:51 PM, Alvaro Herrera wrote:
> *IF* people don't go overboard, yes. I agree, but let's keep an eye so
> that it doesn't become an unreadable mess. I've seen some really
> horrible markdown files that I'm sure most of you would object to.
Markdown++
IME the keys to decen
Hello Hackers,
On Feb 25, 2024, at 13:00, David E. Wheeler wrote:
>> postgres=# SELECT to_regtypemod('timestamp(-4)');
>> ERROR: syntax error at or near "-"
>> LINE 1: SELECT to_regtypemod('timestamp(-4)');
>> ^
>>
On Mar 7, 2024, at 23:39, Erik Wienhold wrote:
> I think you need to swap the examples. The text mentions the error case
> first and the NULL case second.
🤦🏻♂️
Thanks, fixed in the attached patch.
David
v11-0001-Add-to_regtypemod-SQL-function.patch
Description: Binary data
Thanks for the reply, Erik. Have appreciated collaborating with you on a few
different things lately!
> On Oct 13, 2023, at 22:50, Erik Wienhold wrote:
>> Hi, finally getting back to this, still fiddling to figure out the
>> differences. From the thread you reference [1], is the point that @@
>
Hackers,
Following up from a suggestion from Tom Lane[1] to improve the documentation of
boolean predicate JSON path expressions, please find enclosed a draft patch to
do so. It does three things:
1. Converts all of the example path queries to use jsonb_path_query() and show
the results, to ma
On Oct 14, 2023, at 16:40, David E. Wheeler wrote:
> Following up from a suggestion from Tom Lane[1] to improve the documentation
> of boolean predicate JSON path expressions, please find enclosed a draft
> patch to do so.
And now I see I can’t spell “Deviations”. Will fix along
On Oct 14, 2023, at 19:51, Erik Wienhold wrote:
> Thanks for putting this together. See my review at the end.
Appreciate the speedy review!
> Nice. This really does help to make some sense of it. I checked all
> queries and they do work out except for two queries where the path
> expression
On Oct 15, 2023, at 23:03, Erik Wienhold wrote:
> Your call but I'm not against including it in this patch because it
> already touches the modes section.
Okay, added, let’s just put all our cards on the table. :-)
>> Agreed. Would be good if we could teach these functions and operators
>> to r
On Oct 16, 2023, at 18:07, Erik Wienhold wrote:
>> Okay, added, let’s just put all our cards on the table. :-)
>
> I'll have a look but the attached v3 is not a patch but some applefile.
Weird, should be no different from previous attachments. I believe Apple Mail
always uses application/octet
On Oct 19, 2023, at 01:22, jian he wrote:
> "Do not use with non-predicate", double negative is not easy to
> comprehend. Maybe we can simplify it.
>
> 16933: value. Use only SQL-standard JSON path expressions, not not
> there are two "not".
>
> 15842: SQL-standard JSON path exp
On Oct 19, 2023, at 10:49 PM, Erik Wienhold wrote:
> Just wanted to take a look at v5. But it's an applefile again :P
I don’t get it. It was the other times too! Are you able to save it with a
.patch suffix?
D
On Oct 22, 2023, at 20:36, Erik Wienhold wrote:
> That's an AppleSingle file according to [1][2]. It only contains the
> resource fork and file name but no data fork.
Ah, I had “Send large attachments with Mail Drop” enabled. To me 20K is not big
but whatever. Let’s see if turning it off fixes
On Oct 23, 2023, at 20:20, Erik Wienhold wrote:
> I thought that you may have missed that one because I saw this change
> that removes the article:
>
>> -In the strict mode, the specified path must exactly match the structure
>> of
>> +In strict mode, the specified path must exactly mat
On Sep 17, 2023, at 18:09, David E. Wheeler wrote:
> I think this is useful, but also that it’s worth calling out explicitly that
> functions do not count as indexable operators. True by definition, of course,
> but I at least had assumed that since an operator is, in a sense, syntax
Hey Hackers,
Quick follow-up to my slew of questions back in [September][1]. I wanted to
update [my patch][2] to note that only JSON Path equality operators are
supported by indexes, as [previously discussed][3]. I thought perhaps adding a
note to this bit of the docs would be useful:
> For th
On Dec 17, 2023, at 16:08, Tom Lane wrote:
> I'd waited because the discussion was still active, and then it
> kind of slipped off the radar. I'll take another look and push
> some form of what I suggested.
Right on.
> That doesn't really address the
> jsonpath oddities you were on about, thou
On Dec 17, 2023, at 13:10, David E. Wheeler wrote:
> Quick follow-up to my slew of questions back in [September][1]. I wanted to
> update [my patch][2] to note that only JSON Path equality operators are
> supported by indexes, as [previously discussed][3].
Should I just add it to
Greetings Hackers,
Been a while! I’m working on some experiments with JSONB columns and GIN
indexes, and have operated on the assumption that JSON Path operations would
take advantage of GIN indexes, with json_path_ops as a nice optimization. But
I’ve run into what appear to be some inconsisten
On Sep 13, 2023, at 01:11, Erik Rijkers wrote:
> "All use of json*() functions preclude index usage."
>
> That sentence is missing from the documentation.
Where did that come from? Why wouldn’t JSON* functions use indexes? I see that
the docs only mention operators; why would the corresponding
On Sep 14, 2023, at 00:41, Tom Lane wrote:
> As far as json in particular is concerned, 8.14.4 jsonb Indexing [4]
> is pretty clear about what is or is not supported.
How do you feel about this note, then?
diff --git a/doc/src/sgml/json.sgml b/doc/src/sgml/json.sgml
index b6c2ddbf55..7dda727f0d
ttle
mini-tutorial on these two operators would be useful.
Meanwhile, I’d like to re-up this question about the index qualification of
non-equality JSON Path operators.
On Sep 12, 2023, at 20:16, David E. Wheeler wrote:
> Issue 3: Index Use for Comparison
> ---
On Sep 15, 2023, at 20:36, Tom Lane wrote:
> I think that that indicates that you're putting the info in the
> wrong place. Perhaps the right answer is to insert something
> more explicit in section 11.2, which is the first place where
> we really spend any effort discussing what can be indexed.
On Sep 15, 2023, at 23:59, Erik Rijkers wrote:
> movie @? '$ ?($.year >= 2023)'
>
> I believe it is indeed not possible to have such a unequality-search use the
> GIN index. It is another weakness of JSON that can be unexpected to those
> not in the fullness of Knowledge of the manual. Yes, t
On Sep 12, 2023, at 21:00, Erik Wienhold wrote:
>> If so, I’d like to submit a patch to the docs talking about this, and
>> suggesting the use of jsonb_path_query() to test paths to see if they return
>> a boolean or not.
>
> +1
I’ve started work on this; there’s so much to learn! Here’s a new
On Sep 16, 2023, at 16:50, Erik Wienhold wrote:
> "For these operators, a GIN index extracts clauses of the form
> **accessors_chain = constant** out of the jsonpath pattern, and does the
> index search based on the keys and values mentioned in these clauses."
>
> I don't know if this is a gener
On Sep 16, 2023, at 18:13, Erik Wienhold wrote:
> Looks like the effect of lax mode which may unwrap arrays when necessary [1].
> The array unwrapping looks like the result of jsonb_array_elements().
>
> It kinda works in strict mode:
>
> SELECT jsonb_path_query(:'json', 'strict $.track.segment
On Sep 17, 2023, at 12:20, Tom Lane wrote:
> After thinking about it for awhile, I think we need some more
> discursive explanation of what's allowed, perhaps along the lines
> of the attached. (I still can't shake the feeling that this is
> duplicative; but I can't find anything comparable unti
The docs for `to_regtype()` say, “this function will return NULL rather than
throwing an error if the name is not found.” And it’s true most of the time:
david=# select to_regtype('foo'), to_regtype('clam');
to_regtype | to_regtype
+
[null] | [null]
But not others:
On Sep 17, 2023, at 19:28, Tom Lane wrote:
>> No, that is precisely the point. The result should be null instead of
>> an error.
>
> Yeah, ideally so, but the cost/benefit of making it happen seems
> pretty unattractive for now. See the soft-errors thread at [1],
> particularly [2] (but search
On Sep 12, 2023, at 21:00, Erik Wienhold wrote:
>> I posted this question on Stack Overflow
>> (https://stackoverflow.com/q/77046554/79202),
>> and from the suggestion I got there, it seems that @@ expects a boolean to be
>> returned by the path query, while @? wraps it in an implicit exists().
Greetings! Long time no see, I know. How are you, Hackers?
I notice from the docs in the Postgres JSONPath type, brackets are described as:
> • Square brackets ([]) are used for array access.
https://www.postgresql.org/docs/current/datatype-json.html#DATATYPE-JSONPATH
Notably they are not us
On Jan 30, 2023, at 08:17, Filipp Krylov wrote:
>> My question: Are there plans to support square bracket syntax for JSON
>> object field name strings like this? Or to update to follow the standard as
>> it’s finalized?
>
> This syntax is a part of "jsonpath syntax extensions" patchset:
> htt
Hell Hackers, long time no email!
I got a bug report for the semver extension:
https://github.com/theory/pg-semver/issues/58
It claims that a test unexpected passes. That is, Test #31 is expected to fail,
because it intentionally tests a version in which its parts overflow the
int32[3] they’
On Sep 26, 2021, at 18:31, Tom Lane wrote:
> I'd bet more along the lines of "your overflow check is less portable than
> you thought”.
Oh well now that you mention it and I look past things, I see we’re using
INT_MAX, but should probably use INT32_MAX.
https://github.com/theory/pg-semver/b
On Sep 26, 2021, at 19:25, Tom Lane wrote:
> More to the point, you should be checking whether strtol reports overflow.
> Having now seen your code, I'll opine that the failing platforms have
> 32-bit long.
Thanks for the pointer, Tom. I believe this fixes that particular issue.
https://githu
On Jun 4, 2024, at 20:45, David E. Wheeler wrote:
> Oh FFS, unwrapping still breaks my brain. You’re right, of course. Here’s a
> new patch that demonstrates that behavior, since that code path is not
> currently represented in tests AFAICT (I would have expected to have broken
>
On Jun 7, 2024, at 10:23, David E. Wheeler wrote:
> Rebased and moved the new tests to the end of the file.
Bah, sorry, that was the previous patch. Here’s v3.
D
v3-0001-Add-tests-for-jsonpath-.-on-arrays.patch
Description: Binary data
Hackers,
Most of the jsonpath methods auto-unwrap in lax mode:
david=# select jsonb_path_query('[-2,5]', '$.abs()');
jsonb_path_query
--
2
5
(2 rows)
The obvious exceptions are size() and type(), which apply directly to arrays,
so no need to unwrap:
david=# select jsonb_path
On Jun 4, 2024, at 03:18, Peter Eisentraut wrote:
> This could possibly be avoided by renaming the symbol in backbranches. Maybe
> something like
>
> #define InitResultRelInfo InitResultRelInfo2
>
> Then you'd get a specific error message when loading the module, rather than
> a crash.
That
On Jun 10, 2024, at 15:39, Andres Freund wrote:
> That's 6 years ago, not sure we can really learn that much from that.
>
> And it's not like it's actually impossible, #ifdefs aren't great, but they are
> better than nothing.
Right, it’s just that extension authors could use some notification t
On Jun 12, 2024, at 8:43 AM, Peter Eisentraut wrote:
>> Right, it’s just that extension authors could use some notification that
>> such a change is coming so they can update their code, if necessary.
>
> I think since around 6 years ago we have been much more vigilant about
> avoiding ABI bre
On Jun 12, 2024, at 8:58 AM, Jelte Fennema-Nio wrote:
> While not strictly an ABI break I guess, the backport of 32d5a4974c81
> broke building Citus against 13.10 and 14.7[1].
>
> [1]: https://github.com/citusdata/citus/pull/6711
Interesting one. We might want to advise projects to use deferent
On Jun 12, 2024, at 10:47, Robert Haas wrote:
> What I think would be useful to document is our usual practices e.g.
> adding new struct members at the end of structs, trying to avoid
> changing public function signatures. If we document promises to
> extension authors, I don't know how much diff
On Jun 12, 2024, at 4:02 PM, David G. Johnston
wrote:
> Adding Andrew.
Thank you.
> I'm willing to call this an open item against this feature as I don't see any
> documentation explaining that string() behaves differently than the others.
Maybe there’s some wording in the standard on this t
Hackers,
Another apparent inconsistency I’ve noticed in jsonpath queries is the
treatment of the && and || operators: They can’t operate on scalar functions,
only on other expressions. Some examples:
david=# select jsonb_path_query('true', '$ && $');
ERROR: syntax error at or near "&&" of json
On Jun 13, 2024, at 11:32, David E. Wheeler wrote:
> Should && and || not also work on scalar operands?
I see the same issue for unary !, too:
david=# select jsonb_path_query('true', '!$');
ERROR: syntax error at or near "$" of jsonpath in
On Jun 13, 2024, at 3:33 PM, Andrew Dunstan wrote:
> What does the spec say about these? What do other implementations do?
Paging Mr. Eisentraut!
:-)
D
On Jun 13, 2024, at 3:53 PM, Andrew Dunstan wrote:
> Hmm. You might be right. Many of these items have this code, but the string()
> branch does not:
> if (unwrap && JsonbType(jb) == jbvArray)
>return executeItemUnwrapTargetArray(cxt, jsp, jb, found,
>
On Jun 13, 2024, at 21:58, Chapman Flack wrote:
david=# select jsonb_path_query('1', '$ >= 1');
>>>
>>> Good point. I can't either. No way I can see to parse that as
>>> a .
>>
>> Whether we note it as non-standard or not is an open question then, but it
>> does work and opens up a documen
1 - 100 of 246 matches
Mail list logo
