On Apr 25, 2025, at 15:23, David E. Wheeler wrote:
> Thank you for the review. Here’s v3*.
V4 removes “/extension” from the end of the `extension_control_path` value.
Best,
David
v4-0001-Flesh-out-docs-for-the-prefix-make-variable.patch
Description: Binary data
signature.asc
Descript
On Apr 25, 2025, at 17:18, Matheus Alcantara wrote:
> Ok, I was testing using extension_control_path = '$system:/my/custom/path'
> (starting with the macro) and it was working as expected, testing with
> the macro at the end does not work.
Great example of why it’s useful to do as much testing a
On Apr 25, 2025, at 07:33, Christoph Berg wrote:
>
> Re: David E. Wheeler
>> +
>> +make install prefix=/etc/postgresql
>
> I'd use /usr/local/postgresql there. "/etc" is just wrong.
Thank you for the review. Here’s v3*.
Best,
David
* Also re
On Apr 25, 2025, at 09:25, Matheus Alcantara wrote:
> Yes, you are right. The problem was where I was asserting
> control->control_dir != NULL. I've moved the assert after the "if
> (!filename)" check that returns an error if the extension was not found.
>
> Attached v3 with this fix and also a
On Mar 19, 2025, at 13:29, David E. Wheeler wrote:
> I think this should at least be documented, but generally feels unexpected to
> me. I’ve attached a patch that fleshes out the docs, along with an example of
> setting `extension_control_path` and `dynamic_library_path` t
On Apr 24, 2025, at 11:18, Matheus Alcantara wrote:
> In v2 I've moved the logic to remove the /extension to
> parse_extension_control_file(), do you think that this Assert on this
> function would still be wrong? IIUC we should always have /extension at
> the end of "control_dir" at this place,
On Apr 23, 2025, at 09:50, Christoph Berg wrote:
> Remembering which path the .control file was found in and from there
> open the extension "directory" doesn't sound too hard. Why does it
> have to be more complicated?
This was my question, as well. Do you have a WIP patch to share, Matheus?
>
On Mar 27, 2025, at 12:21, Peter Eisentraut wrote:
> Interesting. I think to support that, we would need to do a temp install
> kind of thing of the extension, and then point the path settings into that
> temp install directory. Which is probably more sensible anyway.
If it runs against a te
On Mar 21, 2025, at 17:52, Matheus Alcantara wrote:
> Did you miss to attach the patch?
No. You can see it in the archive[1]. Direct link[2].
> Maybe we could make the "extension" part of the extension control path
> explicitly, like Peter has mentioned in his first patch version [1]?.
> If "d
On Mar 20, 2025, at 09:06, Peter Eisentraut wrote:
>
> This is a quick follow-up to the extension_control_path patch. With this
> little additional patch, you can now run "make check" in PGXS-using
> extensions (instead of having to do make install; make installcheck with a
> running instance
On Mar 19, 2025, at 02:42, Peter Eisentraut wrote:
> Committed that, thanks.
🎉
I’ve been meaning to test the patch again, so here goes.
First thing I notice is that prefix= uses the magic to insert “postgresql” into
the path if it’s not already there:
``` console
❯ make PG_CONFIG=~/dev/c/pos
On Mar 15, 2025, at 07:58, Álvaro Herrera wrote:
> It's make. From its info manual:
Oh, that explains it. It hadn’t occurred to me that make could eval strings
passed to it like that, but of course it does.
>
> I'm surprised that you don't need \$\$ though. I wonder if
> make CFLAGS='-Wl,-r
Hello Hackers,
I'm trying to compile an extension with PG_CFLAGS1[1]:
```sh
make PG_CFLAGS='-Wl,-rpath,$ORIGIN'
```
This works, but for some reason the rpath value is truncated:
```console
# chrpath -l src/semver.so
src/semver.so: RUNPATH=RIGIN
```
Do I need to do something different to includ
On Mar 14, 2025, at 17:13, Laurenz Albe wrote:
> It is a quoting issue.
>
> Trial and error showed my that the following works:
>
> make CFLAGS='-Wl,-rpath,\$$ORIGIN'
>
> ... at least when I run it on the shell. Putting it into an RPM spec file
> might require more escaping, no idea.
Confir
On Mar 3, 2025, at 10:05, David E. Wheeler wrote:
> Very nice writeup, thank you. Makes me wish for the bandwidth to get back to
> and start refining the PGXN OCI RFC
Forgot to link to the POC[1]. The RFC[2] is not OCI-specific, but the POC
demonstrates the “full content” version. Will
On Mar 3, 2025, at 08:39, Gabriele Bartolini
wrote:
> As promised, here is a blog article that provides more context and
> information about what this feature will mean in Kubernetes with
> CloudNativePG:
> https://www.gabrielebartolini.it/articles/2025/03/the-immutable-future-of-postgresql-e
Hi Andrew,
On Feb 4, 2025, at 15:34, Andrew Dunstan wrote:
>> I see. I confirm that works. Still, don’t all the other parameters work when
>> passed to any/all targets? Should this one have an extension-specific name?
>
> IDK, I don't understand what you think you're saying when you specify
>
Hi Peter,
> prefix= should only be set when running the "install" target, not when
> building (make all).
I see. I confirm that works. Still, don’t all the other parameters work when
passed to any/all targets? Should this one have an extension-specific name?
>> So I suspect the issue is that,
Greetings old thread.
On Mar 4, 2024, at 07:50, Peter Eisentraut wrote:
> Maybe the way forward here is to write a buildfarm module for this, and then
> see from there what further needs there are.
Given the PostgreSQL 17.1 kerfuffle and the addition of API and API guidance to
the docs (discu
Hello Peter & Co.
On Dec 5, 2024, at 06:07, Peter Eisentraut wrote:
> I've made a bit of progress on this patch, filled in some documentation and
> resolved some TODO markers. Also:
Finally getting around to reviewing this patch. Should it be considered part of
the previous patch[1] for pur
On Dec 26, 2024, at 20:09, Andrei Lepikhov wrote:
> We intentionally wrote a library, not an extension. According to user usage
> and upgrade patterns, it works across the whole instance and in any database
> or locally in a single backend and ends its impact at the end of its life.
The same i
On Dec 23, 2024, at 15:17, Tom Lane wrote:
> How would that work for extensions where the C code is intentionally
> supporting multiple versions of the SQL objects?
I guess some people do that, eh? In that case it wouldn’t.
D
On Dec 11, 2024, at 19:49, Euler Taveira wrote:
>> FWIW, Id like to have some more information in there, without commenting on
>> the specifics.
>
> +1 for the general idea.
Same.
> I received some reports like [1] related to wal2json
> that people wants to obtain the output plugin version. Si
On Nov 29, 2024, at 15:39, Noah Misch wrote:
> Then packagers who are taking the risk of not rebuilding every time will have
> 3 months to prepare, not the 3 days we're currently giving. The point about
> "well-known extensions" is based on my practice of grepping PGXN. That would
> not have fo
On Nov 25, 2024, at 20:56, Tom Lane wrote:
> None of this is a substitute for installing some kind of ABI-checking
> infrastructure; but that project doesn't seem to be moving fast.
These sound great, very useful. I wonder if the guideline docs Peter added
should link to these items (and back).
On Nov 13, 2024, at 16:38, David E. Wheeler wrote:
> I came to this thinking that it was important to keep core (contrib, PL)
> extensions separate from non-core extensions, and if so, it’d be useful to
> have other defaults so that `make install` would go to the right one (site by
On Nov 20, 2024, at 04:05, Peter Eisentraut wrote:
> The path is only consulted if the specified name does not contain a slash.
> So if you do LOAD 'foo', the path is consulted, but if you do LOAD
> '$libdir/foo', it is not. The problem I'm describing is that most extensions
> use the latter
Hi Peter,
Making another pass at this proposal, I’m a bit confused by this issue:
On Nov 12, 2024, at 09:44, David E. Wheeler wrote:
>>>> - The biggest problem is that many extensions set in their control file
>>>>
>>>> module_pathname = '$libdir
On Nov 15, 2024, at 19:30, Tom Lane wrote:
> That text says exactly nothing about what specific code changes to
> make or not make. I'm not sure offhand where (or if) we have this
> documented, but there's an idea that adding fields at the end of
> a struct is safer ABI-wise than putting them in
On Nov 15, 2024, at 16:13, Tom Lane wrote:
> In other words, our current guidelines
> for preserving ABI compatibility actually *created* this disaster,
> because the HEAD change was fine from an ABI standpoint but what
> was done in back branches was not. So we do need to rethink how
> that's w
On Nov 15, 2024, at 12:52, Noah Misch wrote:
> Either way, users of timescaledb should rebuild timescaledb for every future
> PostgreSQL minor release.
Ugh, was really hoping to get to a place where we could avoid requiring
rebuilds of any extension for every minor release. :-( We even added AB
On Nov 7, 2024, at 10:30, David E. Wheeler wrote:
> Last week I tried to integrate all the ideas into this thread and the
> previous[1] into a single proposal that attempts to work through all the
> implications and issues. I’ve drafted it as a blog post[2] and plan to
> publish
On Nov 12, 2024, at 08:25, Peter Eisentraut wrote:
> No, you can also install them into a common directory and mount that one.
> For example, you install the extension at build time into
> /tmp/foo/{lib,share/extension}, you package that up as a disk image, mount it
> at /opt/extensions/myext
On Nov 11, 2024, at 02:16, Peter Eisentraut wrote:
> I implemented a patch along the lines Craig had suggested.
Oh, nice, thank you.
> It's a new GUC variable that is a path for extension control files. It's
> called extension_control_path, and it works exactly the same way as
> dynamic_libr
Hackers,
On Oct 31, 2024, at 16:12, David E. Wheeler wrote:
> I just thought of another one:
Last week I tried to integrate all the ideas into this thread and the
previous[1] into a single proposal that attempts to work through all the
implications and issues. I’ve drafted it as a blog p
On Oct 31, 2024, at 15:41, David E. Wheeler wrote:
> Other Options?
> --
>
> I kind of like Option 2, as it would allow us to eventually support
> non-`CREATE EXTENSION` modules as extensions, too. I imagine distributing,
> say `auto_explain` in an extension di
Fellow Humans,
I’m working on an updated proposal with more detail, and more comprehensive.
But I keep getting a bit caught up on this bit:
On Oct 28, 2024, at 18:19, David E. Wheeler wrote:
>> * Binary-only extensions might also be installed here; the difference is
>> they hav
On Oct 29, 2024, at 13:40, Tristan Partin wrote:
> The backend would create the packages and publish them to the various
> repositories. We would probably need to come up with a dependency manifest
> that listed both build and runtime dependencies.
>
> This would need some massaging, and has v
On Oct 29, 2024, at 14:09, Christoph Berg wrote
> So far, no one has approached me ("the packaging team") about which
> problems I need solved with extensions (apart from the PGSHAREDIR
> issue).
>
>> Is that something people would be interested in? As someone who writes
>> software, I largely f
On Oct 29, 2024, at 14:03, Paul Ramsey wrote:
> At that point you’re better off distributing the extension via the packaging
> system, where you know that all the dependency versions line up correctly.
Yeah. Perhaps it could be mitigated to some degree by requiring a minimum
version of each de
On Oct 29, 2024, at 13:16, Paul Ramsey wrote:
> An apposite choice, since it not only demonstrates depending on a common
> system library, it also demonstrates the way these things loop on each other,
> as curl then depends on libssl, which postgres also depends on.
Ooh, yeah, vicious!
> Rela
On Oct 29, 2024, at 12:23, Paul Ramsey wrote:
> Question for the more knowledgable, how are binary distribution systems like
> Conda and others shipping DLLs such that different packages don’t clobber
> each other?
I’m not familiar with Conda, but from its docs[1], it seems to rely on a value
On Oct 29, 2024, at 13:03, David E. Wheeler wrote:
> That’s fine for Linux, but more challenging for macOS and Windows. It’s also
> an issue that the apt and yum repositories, while having a lot of stuff,
> don’t have all extensions.
Sorry, I think I was too quick to respond ther
On Oct 29, 2024, at 12:23, Paul Ramsey wrote:
> Thanks for this, David,
🤘🏻
> This of course is the area that worries the heck out of me, as someone with
> extensions that includes not just single system dependencies but long chains
> of them (depending on GDAL draws in a huge tree).
Yeah. I
On Oct 29, 2024, at 12:51, Christoph Berg wrote:
> I think this is where the whole idea of "provide binaries outside of
> deb/rpm" is just going to die. You are trying to reinvent a wheel that
> has been running well for decades, including lots of production
> systems. I don't know anyone who wou
eature. Overall I think the proposal doesn’t need to
change, but there are a couple of things to tweak, and I’ve added a list of use
cases I’m aware of below, plus a tangent on the challenges of loading system
DOS.
Quoting a lot and responding inline.
On Oct 10, 2024, at 4:34 PM, David E. Wheeler
On Oct 10, 2024, at 13:20, Ebru Aydin Gol wrote:
> Thanks for your efforts, a secondary directory for extensions is a very
> useful feature.
>
> Is there any updates on the patch?
There haven't been, no, but your reply has chastened me! I’ve now started a
separate thread[1] proposing direct
Hackers,
Back at the end of August, I promised[1]:
> I’ll try to put some thought into a more formal proposal in a new thread next
> week. Unless your Gabriele beats me to it 😂.
I guess I should get off my butt and do it. So let’s do this. Here’s what I
propose.
* When an extension is insta
On Sep 27, 2024, at 12:07, Andrew Dunstan wrote:
> That would defeat being able to chain these.
Not if it’s a different operator. But I’m fine to just keep using ->> at the
end of a chain.
D
On Sep 26, 2024, at 16:45, Alexandra Wang wrote:
> I didn’t run pgindent earlier, so here’s the updated version with the
> correct indentation. Hope this helps!
Oh, nice! I don’t suppose the standard also has defined an operator equivalent
to ->>, though, has it? I tend to want the text output
On Sep 26, 2024, at 13:59, Florents Tselai wrote:
> Speaking of extensible: the jsonpath standard does mention function
> extensions [1] ,
> so it looks like we're covered by the standard, and the mutability aspect is
> an implementation detail. No?
That’s not the standard used for Postgres js
On Sep 17, 2024, at 15:03, Florents Tselai wrote:
> Fallback scenario: make this an extension, but in a first pass I didn’t find
> any convenient hooks.
> One has to create a whole new scanner, grammar etc.
Yeah, it got me thinking about the RFC-9535 JSONPath "Function Extension"
feature[1], w
On Sep 16, 2024, at 18:39, Florents Tselai wrote:
> Here’s an updated version of this patch.
Oh, nice function.
But a broader question for hackers: Is replace() specified in the SQL/JSON
spec? If not, what’s the process for evaluating whether or not to add features
not specified by the spec?
On Sep 16, 2024, at 13:29, Tom Lane wrote:
> 17.0. If we were already past 17.0 I'd have a lot more angst
> about changing this behavior.
Great, very glad it made it in.
D
On Sep 11, 2024, at 15:52, David E. Wheeler wrote:
> WFM, though now I’ll have to go change my port 😂.
I saw this was committed in cb599b9. Thank you!
BTW, will the back-patch to 17 (cc4fdfa) be included in 17.0 or 17.1?
Best,
David
On Sep 11, 2024, at 15:43, Tom Lane wrote:
> Seems to me it should be the jsonpath convention. If the spec
> does require any specific spelling, surely it must be that one.
WFM, though now I’ll have to go change my port 😂.
D
On Sep 11, 2024, at 15:08, Tom Lane wrote:
> Right. I actually lifted the code from convertJsonbScalar in
> jsonb_util.c.
>
> Here's a more fleshed-out patch with docs and regression test
> fixes. I figured we could shorten the tests a bit now that
> the point is just to verify that datestyle
On Sep 11, 2024, at 12:26, Tom Lane wrote:
> Building on that thought, maybe we could fix it as attached?
> This changes the just-committed test cases of course, and I did
> not look at whether there are documentation changes to make.
It looks like that’s what datum_to_json_internal() in json.c
On Sep 11, 2024, at 11:11, Tom Lane wrote:
> What "let result be stringified" behavior are you thinking of,
> exactly? AFAICS there's not sensitivity to timezone unless you
> use the _tz variant, otherwise it just regurgitates the input.
There is stringification of a time, date, or timestamp va
On Sep 11, 2024, at 10:11, Tom Lane wrote:
> [ looks... ] Hmm, it looks like jsonb_path_exists_tz is marked
> stable while jsonb_path_exists is claimed to be immutable.
> So yeah, there's a problem here. I'm not 100% convinced that
> jsonb_path_exists was truly immutable before, but for sure it
On Sep 10, 2024, at 16:17, Tom Lane wrote:
> Not as things stand. If we adopt Peter's nearby position that
> the current behavior is actually buggy, then probably back-patching
> a corrected version would be worthwhile as a part of fixing it.
Oh, I see now that my reply to him points out the sa
On Sep 10, 2024, at 16:10, Peter Eisentraut wrote:
> These JSON path functions are specified by the SQL standard, so they
> shouldn't depend on PostgreSQL-specific settings. At least in new
> functionality we should avoid that, no?
Does that also apply to `datetime(template)`, where it uses t
On Sep 10, 2024, at 14:51, Tom Lane wrote:
> Pushed with a little additional polishing.
Thank you! Do you think it’d be worthwhile to back port to 17?
> I thought the best way to address jian's complaint about DateStyle not
> being clearly locked down was to change horology.sql to verify the
>
On Aug 27, 2024, at 22:24, Craig Ringer wrote:
> `pg_config` only cares about compile-time settings, so I would not
> expect its output to change.
Right, of course that’s its original purpose, but extensions depend on it to
determine where to install extensions. Not just PGXS, but also pgrx and
On Aug 26, 2024, at 17:35, Craig Ringer wrote:
> This looks like a good suggestion to me, it would make the packaging,
> distribution and integration of 3rd party extensions significantly
> easier without any obvious large or long term cost.
Yes!
> Also PGXS, the windows extension build support
On Aug 27, 2024, at 04:56, Gabriele Bartolini
wrote:
> The extension image could follow a naming convention like this (order can be
> adjusted): `-- version>-(-)`. For example, `pgvector-16-0.7.4-bookworm-1` would
> represent the first image built in a repository for pgvector 0.7.4 for
> Post
Hi Hackers,
Apologies for the delay in reply; I’ve been at the XOXO Festival and almost
completely unplugged for the first time in ages. Happy to see this thread
coming alive, though. Thank you Gabriele, Craig, and Jelte!
On Aug 21, 2024, at 19:07, Craig Ringer wrote:
> So IMO this should be
On Aug 1, 2024, at 18:54, Thomas Munro wrote:
> Done (e52a44b8, 91f498fd).
>
> Any elucidation on how and why Windows machines have started using
> UTF-8 would be welcome.
Haven’t been following this thread, but this post reminded me of an issue I saw
with locales on Windows[1]. Could it be th
On Jul 31, 2024, at 05:27, Peter Eisentraut wrote:
> Well, nobody has protested against what we wrote, so I have committed it.
Excellent, thank you!
D
On Jul 19, 2024, at 10:22, David E. Wheeler wrote:
>
> Here’s a rebase on 5784a49. I also updated the commitfest item[1] to link to
> a new pull request[2], since I seem to have turned the other one into the tz
> conversion bug fix.
>
> [1]: https://commitfest.postgresql
On Jul 30, 2024, at 07:59, Andrew Dunstan wrote:
> I have pushed this.
Thank you, Andrew!
D
On Jul 23, 2024, at 07:26, Peter Eisentraut wrote:
> Things like "object" or "object file" or probably wrong-ish. I understand an
> object file to be a .o file, which you can't dlopen directly.
Agreed.
Another option, however, is “dynamically shared object” (DSO), which
corresponds to the us
On Jul 22, 2024, at 03:12, Jeevan Chalke wrote:
> I agree with David that we need to set the tz explicitly as the JsonbValue
> struct maintains that separately.
>
> However, in the attached version, I have added some comments and also, fixed
> some indentation.
Thank you for the review. I cha
On Jul 21, 2024, at 20:54, Michael Paquier wrote:
> What I mean is that the main regression test suite did not complain on
> your original patch posted here:
> https://www.postgresql.org/message-id/A95346F9-6147-46E0-809E-532A485D71D6%40justatheory.com
>
> But the new tests showed a difference,
On Jul 19, 2024, at 15:46, Nathan Bossart wrote:
> The lack of consistent terminology seems at least potentially confusing for
> readers. My first reaction is that "shared library" is probably fine.
That’s the direction I was leaning, as well, but I thought I heard somewhere
that the project u
Hackers,
I’m trying to understand the standard terms for extension libraries. There seem
too a bewildering number of terms used to refer to a shared object library, for
example:
* LOAD[1]:
* “shared library”
* “shared library file”
* dynamic_library_path[2]:
* “dynamically loadable module
On Jul 9, 2024, at 10:45, David E. Wheeler wrote:
>> one tiny complaint would be maybe we need `reset datestyle`.
>
> That’s fair. Done.
Here’s a rebase on 5784a49. I also updated the commitfest item[1] to link to a
new pull request[2], since I seem to have turned the other one
On Jun 27, 2024, at 18:07, David E. Wheeler wrote:
>> Minor nit - misspelled “considerd"
>
> Thank you, Jeremy. V3 attached.
Rebase on 5784a49 attached. I presume this topic needs quite a bit of review
and consensus from the committers more generally.
Best,
David
v4-00
On Jul 10, 2024, at 11:19, David E. Wheeler wrote:
> Oh, and the time and date were wrong, too, because I blindly used the same
> conversion for dates as for timestamps. Fixed in v2.
>
> PR: https://github.com/theory/postgres/pull/7
> CF: https://commitfest.postgresql.org/49/5
On Jul 19, 2024, at 01:42, Michael Paquier wrote:
> Sorry for the delay. Finally came back to it, and applied the tests.
> Thanks!
Awesome, thank you!
> It was fun to see that HEAD was silenced with the first patch of this
> thread that tweaked the behavior with arrays.
Uh, what? Sorry I don’
On Jul 15, 2024, at 07:07, Stepan Neretin wrote:
> Hi! Looks good to me now! Please, register a patch in CF.
> Best regards, Stepan Neretin.
It’s here:
https://commitfest.postgresql.org/48/5017/
Best,
David
On Jul 10, 2024, at 10:54, David E. Wheeler wrote:
> So it should be -7, not -8. Not sure where to tell it to pay proper attention
> to daylight savings time.
Oh, and the time and date were wrong, too, because I blindly used the same
conversion for dates as for timestamps. Fixed in v
On Jul 10, 2024, at 10:33, David E. Wheeler wrote:
> Yeah I don’t know either, but now at least it’s consistent. I’ve attached a
> patch to fix it.
Actually I think there’s a subtlety still missing here:
@@ -2914,7 +2914,7 @@ HINT: Use *_tz() function for time zone support.
On Jul 10, 2024, at 10:33, David E. Wheeler wrote:
> Yeah I don’t know either, but now at least it’s consistent. I’ve attached a
> patch to fix it.
>
> Ideally, I think, we wouldn’t convert the value and determine the offset
> twice, but teach date_timestamptz and timestamp_
On Jul 10, 2024, at 01:48, Junwang Zhao wrote:
> I apply your patch with some minor change(to make the server not crash):
Oh, thank you! Kicking myself for not catching the obvious.
> It now gives the local tz:
>
> [local] postgres@postgres:5432-54960=# set time zone 'America/New_York';
> SET
On Jul 9, 2024, at 11:08, Junwang Zhao wrote:
> In JsonbValue.val.datatime, there is a tz field, I think that's where
> the offset stored, it is 18000 in the first example
>
> struct
> {
> Datum value;
> Oid typid;
> int32 typmod;
> int tz; /* Numeric time zone, in seconds, for
> * Time
On Jul 9, 2024, at 10:35, jian he wrote:
> one tiny complaint would be maybe we need `reset datestyle`.
That’s fair. Done.
D
v2-0001-Document-impact-of-datestyle-on-jsonpath-string.patch
Description: Binary data
On Jul 9, 2024, at 10:07, David E. Wheeler wrote:
> So perhaps I had things reversed before. Maybe it’s actually doing the right
> then when it converts a timestamp to a timestamptz, but not when it the input
> contains an offset, as in your example.
To clarify, there’s an inconsi
> On Jul 8, 2024, at 21:44, Junwang Zhao wrote:
>
> # select jsonb_path_query_tz('"2024-08-15 12:34:56-05"', '$.timestamp_tz()');
>
> Do you also expect this to show the time in America/New_York?
>
> This is what I get:
>
> [local] postgres@postgres:5432-28176=# select
> jsonb_path_query_tz
On Jul 2, 2024, at 10:53, David E. Wheeler wrote:
> ``` patch
> --- a/src/test/regress/expected/jsonb_jsonpath.out
> +++ b/src/test/regress/expected/jsonb_jsonpath.out
> @@ -2914,7 +2914,7 @@ HINT: Use *_tz() function for time zone support.
> select jsonb_path_query_
On Jul 8, 2024, at 12:17, David G. Johnston wrote:
> We created a data type named: jsonpath. Does the standard actually have that
> data type and defined parsing behavior or does it just have functions where
> one of the inputs is text whose contents are a path expression?
Ah, got it.
D
On Jul 8, 2024, at 12:05, David G. Johnston wrote:
> If we go down this path wouldn't the correct framing be: do not allow
> accessors after scalars ? The same argument applies to false/"john" and
> other scalar types since by definition none of them have subcomponents to be
> accessed.
Yes
On Jun 27, 2024, at 04:17, Michael Paquier wrote:
> The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
> jsonb_path_query with the lax and strict modes, so shouldn't these
> additions be grouped closer to the existing tests rather than added at
> the end of the file?
I’ve move
On Jun 25, 2024, at 18:31, David E. Wheeler wrote:
> For those who prefer a GitHub patch review experience, see this PR:
>
> https://github.com/theory/postgres/pull/3/files
Rebased and restored PGC_SUSET in the attached v5 patch, plus noted the
required privileges in the docs.
Bes
Hi, following up on some old threads.
> On Apr 10, 2024, at 16:44, David E. Wheeler wrote:
>
> That makes sense, thanks. It’s just a little odd to me that the resulting
> path isn’t a query at all. To Erik’s point: what path can `'0x2.p10` even
> select?
I’m wondering
On Jul 4, 2024, at 04:28, jian he wrote:
> Do you need to reset the datestyle?
Wouldn’t hurt but it’s not necessary, no. It’s set only for the execution of
this file, and there are no more calls that rely on it.
> also the above query is time zone sensitive, maybe the time zone is
> set in ano
Hackers,
In fuzing around trying to work out what’s going on with the formatting of
timestamptz values cast by the timestamp_tz() jsonpath method[1], I noticed
that the formatting of the string() method applied to date and time objects was
not fully tested, or how the output is determined by th
On Jul 1, 2024, at 11:02, David E. Wheeler wrote:
> Anyway, should the output of timestamptz JSONB values be made more
> consistent? I’m happy to make a patch to do so, but could use a hand figuring
> out where the behavior varies.
I think if the formatting was more consistent,
Hackers,
There’s an odd difference in the behavior of timestamp_tz() outputs. Running
with America/New_York as my TZ, it looks fine for a full timestamptz, identical
to how casting the types directly works:
david=# set time zone 'America/New_York';
SET
david=# select '2024-08-15 12:34:56-04'::
On Jun 27, 2024, at 17:48, Jeremy Schneider wrote:
> Minor nit - misspelled “considerd"
Thank you, Jeremy. V3 attached.
Best,
David
v3-0001-Add-API-an-ABI-guidance-to-the-C-language-docs.patch
Description: Binary data
1 - 100 of 253 matches
Mail list logo
