> Previously, both "AT TIME ZONE" and "AT LOCAL" were wrapped in a
> single tag, which was incorrect.
Agreed.
> This patch separates them into two distinct tags for better
> semantic correctness.
>
> Please review and apply if appropriate.
> Noboru Saito
Looks good to me.
Best regards,
--
Ta
> On 8 May 2025, at 08:36, Noboru Saito wrote:
>
> Hi,
>
> Previously, both "AT TIME ZONE" and "AT LOCAL" were wrapped in a
> single tag, which was incorrect.
> This patch separates them into two distinct tags for better
> semantic correctness.
Thanks for the patch, it looks correct to me so
On Thu, 8 May 2025 at 15:23, David G. Johnston
wrote:
> Not liking the proposal, not sure it is even correct. Somehow "children of
> inheritance parent tables" are omitted.
I don't see the quoted text anywhere in this area, so I'm not sure I
follow what you mean with the omission.
> In both c
Hi,
Previously, both "AT TIME ZONE" and "AT LOCAL" were wrapped in a
single tag, which was incorrect.
This patch separates them into two distinct tags for better
semantic correctness.
Please review and apply if appropriate.
Noboru Saito
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sg
On Fri, May 02, 2025 at 04:21:21PM -0500, Sami Imseih wrote:
> postgres_fdw, as an example, in which cursor name get reused
> for different queries. Notice below "c1" and "c2" is reused for different
> queries, so now what underlying sql is FETCH, i.e. FETCH 100 FROM c1 referring
> to? v2-0001 does
On Wed, May 7, 2025 at 4:36 PM Nisha Moond wrote:
>
>
> Attached is the v13 patch with the above comments addressed.
>
> --
Thanks for the patch.
I think we can have the restriction mentioned under the 'two_phase'
section as well along with the 'failover' section in the CREATE
SUBSCRIPTION doc,
On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote:
> Ah, I see what you mean. I think the idea is fine, it will simplify
> certain things as well as address the issue. But I'm afraid adding
> start/end location to A_Expr is a bit too invasive, as it's being used
> for many other purpose
On Wed, May 7, 2025 at 10:56 PM Álvaro Herrera wrote:
>
> Ooh, you know what? I ran your the CREATE DOMAIN statement in your new
> test and pg_dump'ed that, and as far as I can tell the _name_ of the
> not-null constraint is not dumped either. So it's not just the comment
> that we're losing. T
On Wed, May 07, 2025 at 10:41:23PM -0500, Nathan Bossart wrote:
> The attached patch should address everything I've mentioned.
And this version of the patch should be free of my embarrassing copy/paste
mistakes.
--
nathan
>From c5460d594a225d3443f901e79c6c9bc7501bd9af Mon Sep 17 00:00:00 2001
Fr
On Wed, May 7, 2025 at 4:15 PM David Rowley wrote:
> In [1] there's a bug report about ALTER TABLE ... ALTER COLUMN SET
> (n_distinct = N) not working for partitioned tables. Of course, you
> need to use n_distinct_inherited for partitioned tables, but the docs
> don't say that.
>
> I went throug
On Wed, May 07, 2025 at 10:29:43AM -0400, Greg Sabino Mullane wrote:
> On Wed, May 7, 2025 at 4:55 AM Ian Lawrence Barwick
> wrote:
>> Version which applies/builds against current HEAD attached. I haven't yet
>> had a chance to look at the code beyond fixing it, however.
I spent some time on this
On Wed, May 07, 2025 at 11:40:14AM +0300, Nikita Malakhov wrote:
> Michael, what do you think of this approach (extending varatt_external)
> vs extending varatt itself by new tag and structure?
I'm reserved on that. What I'm afraid here is more complications in
the backend code because we have qu
On Thu, May 8, 2025 at 01:16:45PM +1200, David Rowley wrote:
> On Thu, 8 May 2025 at 13:11, Bruce Momjian wrote:
> > Ah, I see those now. It was two commits. For some reason the edits are
> > hard for me; applied patch attached.
>
> Thanks. There's been lots of work done in the last year, so
On Thu, 8 May 2025 at 13:11, Bruce Momjian wrote:
> Ah, I see those now. It was two commits. For some reason the edits are
> hard for me; applied patch attached.
Thanks. There's been lots of work done in the last year, so lots of
work to understand it all to a level where you can write meanin
On Thu, May 8, 2025 at 12:47:22PM +1200, David Rowley wrote:
> On Thu, 8 May 2025 at 12:36, Bruce Momjian wrote:
> > +Change pg_backend_memory_contexts.level and
> > pg_log_backend_memory_contexts()() to be one-based (Melih Mutlu, Fujii
> > Masao)
>
> There's an extra set of parentheses on tha
On Thu, 8 May 2025 at 12:36, Bruce Momjian wrote:
> +Change pg_backend_memory_contexts.level and
> pg_log_backend_memory_contexts()() to be one-based (Melih Mutlu, Fujii Masao)
There's an extra set of parentheses on that function name. There's
also an inconsistency between the commit link you ad
On Wed, May 07, 2025 at 04:39:17PM -0700, Nikhil Kumar Veldanda wrote:
> In patch v21, va_compressed.va_data points to varatt_cmp_extended, so
> adding it isn’t strictly necessary. If we do want to fold it into the
> varattrib_4b union, we could define it like this:
>
> ```
> typedef union
> {
>
On Thu, May 8, 2025 at 09:33:49AM +1200, David Rowley wrote:
> On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> > You can see the most current HTML-built version here:
> >
> > https://momjian.us/pgsql_docs/release-18.html
>
> You might have left it out on purpose as the output isn't l
Hello! I'm still trying to figure out those CI failures, I just wanted
to update things.
>From my testing, with this patch repeatedly disabling/enabling
checksums is about 12.4% on an approximately 15 GB database.
By the way, I'd love it if anyone could help me figure out how to
replicate a CI fa
On Wed, May 07, 2025 at 02:55:49PM -0500, Nathan Bossart wrote:
> Committed with that change. That takes care of a good chunk of these TOAST
> snapshot problems. I think there are about 4 others left, unless something
> has changed since I last checked. I hope to look into those again soon.
Tha
On Wed, 7 May 2025 14:36:35 -0700
Masahiko Sawada wrote:
> On Wed, May 7, 2025 at 6:23 AM Yugo Nagata wrote:
> >
> > On Wed, 7 May 2025 15:39:26 +0900
> > torikoshia wrote:
> >
> > > Hi,
> > >
> > > I noticed that REJECT_LIMIT, an option available for COPY FROM, is not
> > > currently supported
Hi Michael, Thanks for the feedback.
On Wed, May 7, 2025 at 12:49 AM Michael Paquier wrote:
>
> I have been reading 0001 and I'm finding that the integration does not
> seem to fit much with the existing varatt_external, making the whole
> result slightly confusing. A simple thing: the last bit
In [1] there's a bug report about ALTER TABLE ... ALTER COLUMN SET
(n_distinct = N) not working for partitioned tables. Of course, you
need to use n_distinct_inherited for partitioned tables, but the docs
don't say that.
I went through a few iterations of the wording to make this clearer
and lande
Jacob Champion writes:
> On Wed, May 7, 2025 at 11:55 AM Fabrízio de Royes Mello
> wrote:
>> Not sure if all animals have a minimum 4.3 make version. Do you?
> Oh, I doubt that very much. I don't immediately see the Make version
> in the configure logs for the animals, but lapwing for example is
On 2025-May-07, Tom Lane wrote:
> Apple is still shipping
>
> $ which make
> /usr/bin/make
>
> $ make --version
> GNU Make 3.81
Well, Jacob did say that he tested it with 3.81, so this patch should be
okay. Upping the minimum version can be discussed elsewhere ... or
maybe never, if we end up
John Naylor writes:
> We prefer that 'a' and 'b' are declared as global variables, just to
> make it as realistic as possible, although it doesn't seem to make
> much difference when I tried it on Compiler Explorer. (Same for
> autoconf)
Yeah, see commit fdb5dd6331e305f797bb589747f056062c305f0b f
On Wed, May 7, 2025 at 8:15 PM Aleksander Alekseev
wrote:
>
> I didn't review the patch but wanted to point out that when it comes
> to performance improvements it's typically useful to provide some
> benchmarks.
+1 -- It's good to have concrete numbers for the commit message, and
also to verify
On Wed, May 7, 2025 at 8:04 PM Eduard Stefes wrote:
>
> Hi,
>
> Here I send a patch that adds a vectorized version of CRC32C for the
> IBM S390X hardware. I kindly ask for a review of the code and to pick
> it up in upstream postgresql.
Thanks!
> # Why this patch:
>
> We noticed that postgres ru
Daniel Gustafsson writes:
> I haven't looked at the test in question yet, but we do skip some SSL tests if
> running against libressl already so I assume this will be able to follow the
> same pattern.
Ah, thanks for the tip. I propose the attached, which disables the
RSA-PSS test altogether on
On Wed, May 7, 2025 at 2:45 PM Jonathan S. Katz wrote:
> I did a double take on the current sentence, and revised it to:
>
> ==
> PostgreSQL 18 introduces `oauth` authentication, which lets users
> authenticate using OAuth 2.0 mechanisms supported through PostgreSQL
> extensions.
> ==
>
> I don't
On 5/7/25 5:16 PM, Jacob Champion wrote:
On Tue, May 6, 2025 at 8:46 PM Jonathan S. Katz wrote:
Here's the next update
Thanks!
PostgreSQL 18 introduces `oauth` authentication, which people can create
extensions that support OAuth 2.0 based authentication mechanisms that
PostgreSQL can aut
On 5/7/25 4:54 PM, Bruce Momjian wrote:
On Tue, May 6, 2025 at 11:24:44PM -0400, Jonathan Katz wrote:
On 5/6/25 11:17 AM, Nathan Bossart wrote:
IMHO we should emphasize that MD5 password support will be removed in a
future release and that users should migrate to something else soon. I'm
ima
On 5/7/25 5:38 AM, Matthias van de Meent wrote:
On Mon, 5 May 2025 at 21:07, Jonathan S. Katz wrote:
Hi,
Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
The goal of this announcement is to introduce the new capabilities
planned for PostgreSQL 18 and give users an idea of
On Wed, May 7, 2025 at 6:23 AM Yugo Nagata wrote:
>
> On Wed, 7 May 2025 15:39:26 +0900
> torikoshia wrote:
>
> > Hi,
> >
> > I noticed that REJECT_LIMIT, an option available for COPY FROM, is not
> > currently supported in psql's tab completion.
> >
> > Additionally, some options are only valid
On 5/7/25 5:18 AM, Jelte Fennema-Nio wrote:
On Mon, 5 May 2025 at 21:07, Jonathan S. Katz wrote:
Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
It might make sense to add a small sentence like "this release
introduces version 3.2 of the wire protocol, but libpq still us
On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> You can see the most current HTML-built version here:
>
> https://momjian.us/pgsql_docs/release-18.html
You might have left it out on purpose as the output isn't likely to be
read by a machine, but for "Change pg_backend_memory_contexts.
On Fri, 11 Oct 2024 at 16:27, Matthias van de Meent wrote:
>
> Hi,
>
> With PG17's new SAOP handling the performance of certain index scans
> significantly improved performance in the serial case. However, for
> parallel index scans the performance picture is not as
> straightforward, and this has
Thomas Munro writes:
> Oh, interesting. I also wondered if the problem I reported might be
> related to the separate legacy code paths in x509_vfy.c.
I poked at this a little more, and apparently the code to look at is
actually in the sibling file x509_verify.c. Here's the backtrace
(in OpenBSD
On Tue, May 6, 2025 at 8:46 PM Jonathan S. Katz wrote:
> Here's the next update
Thanks!
> PostgreSQL 18 introduces `oauth` authentication, which people can create
> extensions that support OAuth 2.0 based authentication mechanisms that
> PostgreSQL can authenticate with.
Suggested alternative
On Wed, May 7, 2025 at 07:59:41PM +0900, Yugo Nagata wrote:
> On Thu, 1 May 2025 22:44:50 -0400
> Bruce Momjian wrote:
>
> > I have committd the first draft of the PG 18 release notes. The item
> > count looks strong:
>
> Thank you for working on this.
>
> > Have pgbench report the number of
On Tue, May 6, 2025 at 11:24:44PM -0400, Jonathan Katz wrote:
> On 5/6/25 11:17 AM, Nathan Bossart wrote:
>
> > IMHO we should emphasize that MD5 password support will be removed in a
> > future release and that users should migrate to something else soon. I'm
> > imagining it'll still be at lea
On Wed, May 7, 2025 at 03:03:32PM +0900, Richard Guo wrote:
> On Fri, May 2, 2025 at 11:44 AM Bruce Momjian wrote:
> >
> > I have committd the first draft of the PG 18 release notes.
>
> > I will continue improving it until beta 1, and until the final release.
> > I will probably add markup in 1
On Wed, May 07, 2025 at 08:00:39AM +0900, Michael Paquier wrote:
> On Tue, May 06, 2025 at 11:41:49AM -0500, Nathan Bossart wrote:
>> I brought this up with the RMT, and everyone seemed okay with committing it
>> for v18.
>
> Cool, thanks for the update.
>
>> I can move it back to replorigin_crea
On Wed, May 7, 2025 at 11:55 AM Fabrízio de Royes Mello
wrote:
> LGTM
Thanks for the review!
>> Tested with GNU Make 3.81 (the compilation of which was slightly
>> painful; does anyone want to debate pulling that minimum version up
>> sometime soon?) and 4.3.
>
> Not sure if all animals have a m
On Tue, May 6, 2025 at 11:59 PM Amit Kapila wrote:
>
> On Thu, Apr 24, 2025 at 11:14 PM Masahiko Sawada
> wrote:
> >
> > On Thu, Apr 24, 2025 at 5:30 AM Amit Kapila wrote:
> > >
> > > On Wed, Apr 23, 2025 at 9:35 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Apr 23, 2025 at 5:46 AM
> On 7 May 2025, at 21:29, Tom Lane wrote:
>
> I filed a report with the LibreSSL folks, and the answer was basically
> "yeah, we know RSA-PSS doesn't work; there are multiple things that
> need fixing" [1]. So it seems like we'd better find a way to skip
> that test case when using LibreSSL. N
I filed a report with the LibreSSL folks, and the answer was basically
"yeah, we know RSA-PSS doesn't work; there are multiple things that
need fixing" [1]. So it seems like we'd better find a way to skip
that test case when using LibreSSL. Not sure what the most
appropriate check would look like
On Tue, May 6, 2025 at 8:11 PM Mark Dilger wrote:
> I have been using your two patches, one committed by you and the other
> committed locally to my working directory, since you posted them a few days
> ago. I have not encountered any of the problems that I had been encountering
> previously.
On Wed, May 7, 2025 at 2:17 PM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> Hello!
>
> Wolfgang reported over in [1] that I've missed a comma when appending
> to the PKG_CONFIG_REQUIRES_PRIVATE list, making libpq.pc look ugly:
>
> Requires.private: libssl, libcrypto libcurl
>
> p
On Tue, May 06, 2025 at 11:39:33AM -0500, Nathan Bossart wrote:
> I brought this up in the RMT meeting today, and everyone was fine with
> committing it for v18. I'll plan on doing so later this week.
Committed.
--
nathan
> On Tue, May 06, 2025 at 03:01:32PM GMT, Sami Imseih wrote:
> > > Without properly accounting for the boundaries of the list of
> > > expressions, i.e.,
> > > the start and end positions of '(' and ')' or '[' and ']' and normalizing
> > > the
> > > expressions in between, it will be very difficu
Hi all,
I forgot to put a recursion limit in the new OAuth parsers; the
server-side depth checks don't apply to the client, and it's not using
the incremental parser to move the burden from the stack to the heap.
Luckily, we track the nesting level already, so a fix (attached) can
be pretty small.
Hi,
On Wed, May 07, 2025 at 07:28:01AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Wed, May 07, 2025 at 09:10:17AM +0900, Michael Paquier wrote:
> > On Mon, May 05, 2025 at 04:33:20PM +0300, Ilia Evdokimov wrote:
> > > While reviewing the import/export statistics, I noticed that relation
> > > lo
> On 7 May 2025, at 18:04, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 7 May 2025, at 06:34, Tom Lane wrote:
>>> I couldn't help noticing that the backtraces went through
>>> lib/libssl/tls13_legacy.c, which doesn't give a warm feeling
>>> about how supported they think our usage is (a
Hello!
Wolfgang reported over in [1] that I've missed a comma when appending
to the PKG_CONFIG_REQUIRES_PRIVATE list, making libpq.pc look ugly:
Requires.private: libssl, libcrypto libcurl
pkg-config itself appears to be papering over my mistake (a quick code
inspection suggests it treats co
Robert Haas writes:
> On Mon, May 5, 2025 at 8:35 AM Robert Haas wrote:
>> So it seems like the only real fix is to do as Tom proposes:
>> # But don't we need to add
>> # createrole_self_grant to the set of GUCs that pg_dump[all]
>> # resets in the emitted SQL?
> Tom, are you hoping that I'm goi
On Mon, May 5, 2025 at 8:35 AM Robert Haas wrote:
> So it seems like the only real fix is to do as Tom proposes:
>
> # But don't we need to add
> # createrole_self_grant to the set of GUCs that pg_dump[all]
> # resets in the emitted SQL?
Tom, are you hoping that I'm going to produce a patch for t
On Tue, May 6, 2025 at 12:19 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Apr 21, 2025 at 10:31:03AM -0700, Masahiko Sawada wrote:
> > I would like to discuss behavioral and user interface considerations.
> >
> > Upon further analysis of this patch regarding the conversion of
> > wal_level to a
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> Weird, that doesn't seem to work very well if you try to search for
> stuff. But if you just specify the Message-Id without clicking "search"
> then it works. So here you go:
> https://commitfest.postgresql.org/patch/5742/
Yeah, that "search" button is
Daniel Gustafsson writes:
>> On 7 May 2025, at 06:34, Tom Lane wrote:
>> I couldn't help noticing that the backtraces went through
>> lib/libssl/tls13_legacy.c, which doesn't give a warm feeling
>> about how supported they think our usage is (and perhaps also
>> explains why they didn't detect th
Ooh, you know what? I ran your the CREATE DOMAIN statement in your new
test and pg_dump'ed that, and as far as I can tell the _name_ of the
not-null constraint is not dumped either. So it's not just the comment
that we're losing. That's a separate bug, and probably needs to be
fixed first, altho
On Tue, May 06, 2025 at 11:24:44PM -0400, Jonathan S. Katz wrote:
> I took most of these changes. I don't think we should add the MD5 "will be
> removed in a future release" in the beta announcement, as that could lead to
> confusion (e.g. it's removed in beta 2!). I'm fine with adding that in the
On Mon, May 05, 2025 at 02:23:25PM -0500, Nathan Bossart wrote:
> That leaves pg_shdepend. For now, I've just instructed pg_upgrade to COPY
> the relevant pg_shdepend rows as an independent step, but perhaps there's a
> reasonably straightforward way to put that in pg_dump, too.
It turns out ther
On Wed, May 7, 2025 at 5:25 PM Álvaro Herrera wrote:
>
> On 2025-May-07, jian he wrote:
>
> > in PG17 and master, pg_dump (--schema=test --no-owner)
> > [...]
> > didn't produce
> > COMMENT ON CONSTRAINT nn ON DOMAIN test.d1 IS 'not null constraint on
> > domain d1';
> > we should make pg_dump to
On Wed, May 7, 2025 at 4:55 AM Ian Lawrence Barwick
wrote:
> Version which applies/builds against current HEAD attached. I haven't yet
> had a chance to look at the code beyond fixing it, however.
>
I too, have wanted this over the years, so +1 on the idea.
Quick review: nice patch, very thorou
On Tue, 6 May 2025 at 21:29, Nathan Bossart wrote:
>
> Every once in a while, I find myself wanting to use regdatabase for
> something like current_database()::regdatabase, and I'm always surprised
> when I inevitably rediscover that it doesn't exist.
+1 for the idea. I keep running into this too
Hello,
Attached are the updated files to help reproduce the state mentioned in the
previous email more easily.
- The load_data.sql has the commands to insert a lot of dummy data that
will overflow to TOAST
- Which then is deleted (via the commands in the sql file) to create a
situation where a
On Wed, 7 May 2025 15:39:26 +0900
torikoshia wrote:
> Hi,
>
> I noticed that REJECT_LIMIT, an option available for COPY FROM, is not
> currently supported in psql's tab completion.
>
> Additionally, some options are only valid for COPY FROM or COPY TO, i.e.
> FREEZE, ON_ERROR, FORCE_QUOTE, bu
Hi Eduard,
> Here I send a patch that adds a vectorized version of CRC32C for the
> IBM S390X hardware. I kindly ask for a review of the code and to pick
> it up in upstream postgresql.
> [...]
> Cheers and thanks to all for their work,
Thanks for submitting this patch.
Please register it on the
Hi,
Here I send a patch that adds a vectorized version of CRC32C for the
IBM S390X hardware. I kindly ask for a review of the code and to pick
it up in upstream postgresql.
# Why this patch:
We noticed that postgres running on an S390X will spend much longer in
CRC32C as compared to other platf
Hi Robert,
On Mon, May 5, 2025 at 8:07 AM Robert Haas wrote:
> I don't understand why we need this. I don't see why we need any sort
> of generalized concept of metadata at all here. The zstd-dict
> compression method needs to store a four-byte OID, so let it do that.
> But we don't need to brand
On Wed, May 7, 2025 at 10:32 AM shveta malik wrote:
>
> On Mon, May 5, 2025 at 3:29 PM Nisha Moond wrote:
> >
> > Please find the v12 patch with above suggested changes.
> >
>
> Thanks for the patch. Few comments for doc changes:
>
> 1)
> func.sgml - pg_create_logical_replication_slot:
>
> +
On Thu, 1 May 2025 22:44:50 -0400
Bruce Momjian wrote:
> I have committd the first draft of the PG 18 release notes. The item
> count looks strong:
Thank you for working on this.
> Have pgbench report the number of failed transactions (Yugo Nagata)
I think that should be
"Have pgbench repo
On 2025-May-07, Andrei Lepikhov wrote:
> Yes,
> The magic is how it finds a link to the thread. This time it doesn't find it
> by link:
> https://www.postgresql.org/message-id/c0c19730-7fec-4c78-bff8-b87ee42b7...@gmail.com
> or just a thread-id:
> c0c19730-7fec-4c78-bff8-b87ee42b7...@gmail.com
We
On 7/5/2025 09:57, Álvaro Herrera wrote:
On 2025-May-07, Andrei Lepikhov wrote:
Hi,
Because there was no answer to the issue [1], I'll add it to the next
commitfest. Feel free to reject it if my logic on choosing the merge append
path is wrong.
If this is a bug new in pg18, you should add an
On Mon, 5 May 2025 at 21:07, Jonathan S. Katz wrote:
>
> Hi,
>
> Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
> The goal of this announcement is to introduce the new capabilities
> planned for PostgreSQL 18 and give users an idea of areas we'd like to
> see tested.
>
> Ple
On 2025-May-07, jian he wrote:
> in PG17 and master, pg_dump (--schema=test --no-owner)
> [...]
> didn't produce
> COMMENT ON CONSTRAINT nn ON DOMAIN test.d1 IS 'not null constraint on
> domain d1';
> we should make pg_dump to produce it too?
Yes, this is clearly a pg17 bug whose fix should be ba
On 7/5/2025 11:12, Álvaro Herrera wrote:
On 2025-May-07, Andrei Lepikhov wrote:
If it's not new in pg18, then adding a commitfest entry in the "bug
fixes" category is the right thing. I'd suggest to CC the committer and
author of the patch that caused the bug; with the amount of traffic in
pgs
On Mon, 5 May 2025 at 21:07, Jonathan S. Katz wrote:
> Attached is a draft of the PostgreSQL 18 Beta 1 release announcement.
It might make sense to add a small sentence like "this release
introduces version 3.2 of the wire protocol, but libpq still uses 3.0
by default. This is the first new proto
On 2025-May-07, Andrei Lepikhov wrote:
> > If it's not new in pg18, then adding a commitfest entry in the "bug
> > fixes" category is the right thing. I'd suggest to CC the committer and
> > author of the patch that caused the bug; with the amount of traffic in
> > pgsql-hackers these days, it's
On 2025/05/05 23:57, Robert Haas wrote:
On Fri, May 2, 2025 at 9:54 PM Fujii Masao wrote:
Thanks for the review and testing! I've fixed the issue you pointed out.
Updated patch attached.
Thanks for addressing this. However, I believe this commit may need to
take note of the following commen
Andrei Lepikhov писал(а) 2025-05-07 12:03:
On 7/5/2025 08:57, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-07 08:02:
On 5/5/2025 15:56, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-05 14:38:
Also logic a bit differs if path is NULL. In
get_cheapest_path_for_pathkeys_
hi.
begin;
create schema test;
set search_path to test;
create domain d1 as int;
alter domain d1 add constraint nn not null;
alter domain d1 add constraint cc check (value is not null);
comment on constraint nn on domain d1 is 'not null constrai
On 7/5/2025 08:57, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-07 08:02:
On 5/5/2025 15:56, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-05 14:38:
Also logic a bit differs if path is NULL. In
get_cheapest_path_for_pathkeys_ext() we explicitly check for path
being NU
2025年5月7日(水) 10:47 Nathan Bossart :
>
> On Wed, May 07, 2025 at 09:18:28AM +0900, Ian Lawrence Barwick wrote:
> > Hah, I put together a patch to implement just that a while back, but
> > then concluded
> > for some reason that it would likely be rejected so saved myself the
> > humiliation of
> > s
On 2025-May-06, Jonathan S. Katz wrote:
> Here's the next update (CCing folks who commented); I added a sentence on
> the new constraints that are available in the developer experience section,
> and the sentence around the behavior towards the bottom. Please let me know
> if you think this suffic
Hi!
Michael, what do you think of this approach (extending varatt_external)
vs extending varatt itself by new tag and structure? The second approach
allows more flexibility, independence of existing structure without
modifying
varatt_4b and is extensible further. I mentioned it above (extending
th
On 2025-May-07, Andrei Lepikhov wrote:
> Hi,
>
> Because there was no answer to the issue [1], I'll add it to the next
> commitfest. Feel free to reject it if my logic on choosing the merge append
> path is wrong.
If this is a bug new in pg18, you should add an item to the "open items"
list here
Hello again,
I did prepare another patch, which introduces an xmltype-based alternative
for xslt_process(). I would really like to put that up for discussion. IMHO
with this patch, xslt_process() should be ready to be adopted into core.
Unfortunately, it cleanly applies only on top of the error h
On Sun, May 04, 2025 at 05:54:34AM -0700, Nikhil Kumar Veldanda wrote:
> 3. Resulting on-disk layouts for zstd
>
> ZSTD (nodict) — datum on‑disk layout
>
> +--+
> | va_header (uint32) |
> +--+
> | va_tcinfo (uint32)
Hi,
On Wed, May 07, 2025 at 09:10:17AM +0900, Michael Paquier wrote:
> On Mon, May 05, 2025 at 04:33:20PM +0300, Ilia Evdokimov wrote:
> > While reviewing the import/export statistics, I noticed that relation
> > locking are handled via relation_open() and relation_close() in
> > stats_lock_check_
91 matches
Mail list logo
