On Jul 29, 2025, at 08:25, Daniel Gustafsson wrote:
> The attached version also adds a commit message, tweaks the documentation
> along
> with a few small changes to error message handling etc.
This looks great. One nit my editor noticed: This line:
+-- Round-trip test for all lengths from 0–4
On Jul 13, 2025, at 15:43, Tom Lane wrote:
> I'm still liking the in-tree-file idea better. For one thing,
> it's not clear how expensive it'd be to search the git metadata
> for this other stuff.
How bout we keep it a simple as possible to start with: make it either the last
tag in the branch
On Jul 13, 2025, at 15:02, Tom Lane wrote:
> On reflection, assuming that this is being run by one or more
> buildfarm animals, there are not likely to be so many commits
> between runs that it'll be hard to assign blame after a breakage.
> So I'm not convinced that we need to build the logic you
On Jul 13, 2025, at 14:34, Mankirat Singh wrote:
> Here, I had a proposal: In case an ABI break is found, then loop
> through the commits after the last run to find the offending commit.
> We can also give the animal owner the option to decide whether they
> want to use their own machine to perfo
On Jul 11, 2025, at 04:26, Florents Tselai wrote:
> Attached
Thank you! This looks great. The attached revision makes a a couple of minor
changes:
* Change the line wrap of the docs to be more like the rest of func.sgml
* Remove an unnecessary nested if statement
* Removed `==` from one of t
On Jul 12, 2025, at 00:07, Florents Tselai wrote:
> To recap so far;
>
> - I like your changes and renames on the parser/lexer; it indeed looks much
> cleaner now and will help with future improvements.
Thanks!
> - I also like the addition of executeStringInternalMethod ; it'll help us add
On Jul 10, 2025, at 19:23, David E. Wheeler wrote:
> Now with the `ISO C90 forbids mixed declarations and code` warning cleared up.
>
> Weird that there’s a failure on Bookworm with Meson [1] (pg_regress diffs
> [2]) but not Bookworm with Configure [3]. Collation issue, perhaps?
D
On Jul 10, 2025, at 18:40, David E. Wheeler wrote:
> Resolved in the attached, which now passes `make check-world` for me.
>
> Also available as a pull request[1].
Now with the `ISO C90 forbids mixed declarations and code` warning cleared up.
Weird that there’s a failure on Book
On Jul 10, 2025, at 14:13, David E. Wheeler wrote:
> Oh, is that what’s happening? What needs to happen to properly support
> pg_upgrade?
Turns out there was an assertion failure that David Johnson spotted in the core
dump of the test output and then in the regress log. Turns out I
On Jul 10, 2025, at 16:38, Florents Tselai wrote:
> Why isn’t this sufficient?
>
> static uint64
> pg_base64_encode_internal(const char *src, size_t len, char *dst, bool url)
> {
> const char *alphabet = url ? _base64url : _base64;
Ah, it is. I hadn’t got that far. I was tripped up to see this
Hi Florents,
On Jul 9, 2025, at 23:25, Florents Tselai wrote:
>> I reviewed and tested v4. To me it looks as good as it will get.
>> Personally I would change a few minor things here and there and
>> probably merge all three patches into a single commit. This however is
>> up to the committer to
On Jul 10, 2025, at 13:41, Florents Tselai wrote:
> The basic problem I see with these latest revisions/refactorings is that they
> fail for pg_upgrade afaict.
> Probably this means that some of the rearrangements on the parser/scanner are
> not that flexible.
Oh, is that what’s happening? Wha
On Jul 9, 2025, at 11:33, Andres Freund wrote:
> It'd be nice if we could get there, but it'd require annotating *all*
> intentionally exported functions in the backend with PGDLLIMPORT (rather than
> just doing that for variables). Then we could make some symbols
> *intentionally* not exported,
Hello,
This is an interesting proposal, thanks for posting.
On Jul 3, 2025, at 11:00, Ross Heaney wrote:
> Proposed Improvements
> Instead we can relax the assumption that it must be an integer value for k.
> To do this we split the k value into an integer and a rational part. Call
> this k
On Jun 19, 2025, at 12:59, Thom Brown wrote:
> No. But given the options, I would personally choose nondeterministic
> collations now that they are available. I just wish they were more
> user-friendly as I suspect the majority of people either won't know about
> them, or won't know how to use
On Jun 4, 2025, at 11:27, David E. Wheeler wrote:
> And these should fix the CI failure. I also ran pgindent.
Here’s a quick rebase. I think it’s ready for committer review, but since I’ve
poked at it quite a bit myself, I updated the Commitfest item [1] to “Needs
Review”.
Best,
David
On Jun 11, 2025, at 17:43, Tom Lane wrote:
> I fear that that would cause some problems. Consider
>
> regression=# select '["foo", "bar"]'::jsonb - 'bar';
> ?column?
> --
> ["foo"]
> (1 row)
>
> Right now we resolve the unlabeled literal as type text.
> But if jsonb - jsonb existed, w
On Jun 11, 2025, at 16:03, Robert Haas wrote:
> The proposed behavior of the operator you want to add would be
> inconsistent with the existing integer subtraction operator, because
> the former would remove by value and the latter removes by index.
Bear in mind that `-` currently does both. Of
On Jun 7, 2025, at 16:20, Mark Dake wrote:
> Support a jsonb - jsonb operator where, if the RHS is a scalar that appears
> in the LHS array, the operator removes all matching values:
> SELECT jsonb('[2,3,1]') - to_jsonb(1);
> -- Expected: [2, 3]
> This would mirror similar behavior in many appli
On Jun 4, 2025, at 12:10, Andres Freund wrote:
> No. It just makes the *name* of the struct visible. The type's definition is
> in the .c file and therefore not visible outside of read_stream.c.
Right, got it, thanks.
David
signature.asc
Description: Message signed with OpenPGP
Hi Jeff,
On Jun 3, 2025, at 23:22, Jeff Davis wrote:
> If we didn't have separate markers, we'd need to assume that all of
> those objects could be affected by a provider update.
I understand the need to trace these dependencies, but as a function developer
with relatively modest understanding
On Jun 3, 2025, at 15:10, David E. Wheeler wrote:
>> https://github.com/theory/postgres/pull/12
>
> Found a little more unnecessary code to remove. Updated patches attached.
And these should fix the CI failure. I also ran pgindent.
Best,
David
v8-0001-Rename-jsonpat
On Jun 4, 2025, at 09:43, Álvaro Herrera wrote:
> You mentioned ReadStream, but that's not exported.
I this not an export at line 67?
```
❯ rg ReadStream src/include/storage/read_stream.h
50: * the ReadStreamBlockNumberCB callback to abide by the restrictions of AIO
66:struct ReadStream;
67:ty
On Jun 3, 2025, at 15:02, David E. Wheeler wrote:
> Patches attached, GitHub PR here:
>
> https://github.com/theory/postgres/pull/12
Found a little more unnecessary code to remove. Updated patches attached.
Best,
David
v7-0001-Rename-jsonpath-method-arg-tokens.patch
Descriptio
Hackers,
On May 26, 2025, at 18:00, David E. Wheeler wrote:
> Yes, I think it would be best if the grammar was a bit stricter --- and
> therefore more self-explanatory --- by making the args closer to what the
> functions actually expect.
I chatted with Florents and went ahead and s
On Jun 3, 2025, at 13:23, Mankirat Singh wrote:
>> I don't think it's the
>> job of the tool to determine that this ABI difference is okay.
>> Ultimately that's for a human to determine,
>
> Yes, but it would be better if we could automate that thing to some
> extent, along with the development
Hackers,
I’d like to introduce Mankirat Singh, a Google Summer of Code student that
Pavlo Golub and I are mentoring this year. He’s started work on his project, an
ABI Compliance Checker. The plan is to work out the patterns, integrate it into
the Build Farm, and get it sending regular reports
On May 25, 2025, at 00:16, Florents Tselai wrote:
> The most important problem in jsonpath_scan.l now is the fact that I broke
> the alphabetical ordering of keywords in v2 ,
> and you followed that too.
Oh. They have been organized by length; I didn’t notice they were also
alphabetical.
> Bu
On May 24, 2025, at 17:55, David E. Wheeler wrote:
> And now I see my patch broke the grammar because I left some of my fiddling
> in there. Apologies. Here’s an updated patch with the updated keyword map,
> too.
No, really :sigh:
D
v5-0001-Add-additional-jsonpath-string-meth
On May 24, 2025, at 17:46, David E. Wheeler wrote:
> Oh, and I forgot to mention, src/backend/utils/adt/jsonpath_scan.l looks like
> it has a ton of duplication in it. Shouldn’t it just add the new keywords,
> something like:
And now I see my patch broke the grammar because I left s
On May 24, 2025, at 17:39, David E. Wheeler wrote:
> I’ve attached a new patch with docs.
Oh, and I forgot to mention, src/backend/utils/adt/jsonpath_scan.l looks like
it has a ton of duplication in it. Shouldn’t it just add the new keywords,
something like:
```
@@ -415,6 +415,11 @@ sta
On May 24, 2025, at 12:51, Florents Tselai wrote:
> I think the patch is still in reasonably good shape and hasn’t changed much
> since September 24.So yes, I’d hope there are still some valid points to
> consider or improve.
Okay, here’s a review.
Patch applies cleanly.
All tests pass.
I'm
On May 23, 2025, at 13:52, Tom Lane wrote:
>> I assume you mean that they’re set at initdb time, so there’s no mutability
>> concern?
>
> Yeah, I think Peter's right and I'm wrong. Obviously this ties into
> our philosophical debate about how immutable is immutable. But as
> long as the func
On May 22, 2025, at 12:38, Florents Tselai wrote:
> In my experience timestamp related stuff from jsonb documents end up in a
> generated column,
> and are indexed & queried there.
Have you seen this in the wild using the _tz functions? I wouldn’t think they
were indexable, given the volatilit
On May 21, 2025, at 14:06, Robert Haas wrote:
> No, that wouldn't be too much work, but the issue is that people will
> keep using the _tz versions and when we eventually try to remove them
> those people will complain no matter how prominent we make the
> deprecation notice. If we want to go thi
On May 13, 2025, at 16:24, Florents Tselai wrote:
> As Robert said—and I agree—renaming the existing _tz family would be more
> trouble than it’s worth, given the need for deprecations, migration paths,
> etc. If we were designing this today, suffixes like _stable or _volatile
> might have bee
On May 9, 2025, at 15:50, Robert Haas wrote:
> # We have the kluge of having separate "_tz" functions to support
> # non-immutable datetime operations, but that way doesn't seem like
> # it's going to scale well to multiple sources of mutability.
>
> But I'm not sure I understand why it matters
On May 1, 2025, at 16:24, Peter Eisentraut wrote:
> I see. I have committed it now describing the current state.
Quick follow-up to tweak a couple of commas.
--- a/doc/src/sgml/extend.sgml
+++ b/doc/src/sgml/extend.sgml
@@ -1813,8 +1813,8 @@ include $(PGXS)
You can select a separat
On May 1, 2025, at 16:24, Peter Eisentraut wrote:
> I see. I have committed it now describing the current state.
>
> Btw., the shown directory names that illustrate how "postgresql" is appended
> were not correct. I have corrected that.
Thank you. I gotta say I find them confusing TBH.
Best,
On May 1, 2025, at 07:50, Peter Eisentraut wrote:
> The documentation in config.sgml says:
>
>Note that the path elements should typically end in
>extension if the normal installation layouts are
>followed.
>
> So I think your change here between v3 and v4 is incorrect.
Right, sorr
On Apr 29, 2025, at 11:06, Matheus Alcantara wrote:
> The substitute_path_macro() already handles the if/else on "piece" but I
> think that this if/else version looks nicer. Fixed.
>
> I've also included some documentation changes for this v5 version to
> remove the "extension" from the examples
On Apr 29, 2025, at 09:49, Matheus Alcantara wrote:
> Yes, it is a single path from the search path, in your case it will be
> "/Users/david/Downloads/share/postgresql" and "$system". We split these
> paths based on the system path separator and get the next "piece" here:
>
>char
On Apr 29, 2025, at 09:56, Matheus Alcantara wrote:
> Typo on "io"? Maybe "into" or "in”?
Bah, yes, it’s “to”. Updated in v5 (and also a PR[1] for those who prefer that
UX).
Best,
David
[1]: https://github.com/theory/postgres/pull/10
v5-0001-Flesh-out-docs-for-the-prefix-make-variable.pa
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
1 - 100 of 296 matches
Mail list logo
