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
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
1 - 100 of 280 matches
Mail list logo
