On 03.09.25 13:42, Daniel Gustafsson wrote:
On 3 Sep 2025, at 07:47, Peter Eisentraut wrote:
- Hundreds of compiler warnings (They are not necessarily wrong, but it shows
that no one has taken care to tune the warnings or the code in any way
recently.)
Should these be posted somewhere
On 10.12.24 03:02, Thomas Munro wrote:
And if we included overtly, rather than covertly in
postgres_ext.h, why would we still want a third name for int64_t? We
could change the three lo_*64() declarations to use the standard type
directly, but keep the historical typedef marked deprecated.
Bu
attached.
From 9e41e9ae0837288658d410d355b95909fd58b37e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 3 Sep 2025 15:41:17 +0200
Subject: [PATCH v1] Expand virtual columns in get_relation_constraints()
Otherwise, some opportunities for constraint exclusion will be missed
if a
On 01.09.25 05:25, Michael Paquier wrote:
So, taking a step back, I don't know what would be a good fit for
these duplicates of the "next power" routines upper-bounded on input
when attached to pg_bitutils.h. However, I do see that we can get rid
of pg_log2() and dynahash.h with a consistent int
On 02.09.25 04:57, David Rowley wrote:
On Thu, 24 Jul 2025 at 23:03, Peter Eisentraut wrote:
Please review my patch at
https://www.postgresql.org/message-id/ccb273c9-7544-4748-8638-30feba212...@eisentraut.org
https://commitfest.postgresql.org/patch/5934/
Now that we're building wit
On 03.09.25 11:39, Richard Guo wrote:
On Wed, Sep 3, 2025 at 5:41 PM Peter Eisentraut wrote:
I have committed this with a few of the small changes mentioned nearby.
copperhead reported just now a test failure in test_oat_hooks:
SET debug_discard_caches = 0;
+ERROR: unrecognized
On 01.09.25 09:21, John Naylor wrote:
On Thu, Aug 28, 2025 at 1:53 PM Peter Eisentraut wrote:
Ok, good suggestions. I addressed all those, and did another cleanup
pass over the script. (The formatting is from pgperltidy.)
I have no further comments on v3.
I have committed this with a few
On 28.08.25 20:03, David E. Wheeler wrote:
On Aug 28, 2025, at 09:29, Daniel Gustafsson wrote:
A tiny nitpick is that all the other generator scripts (that I looked at) in
the tree use GetOptions() with named parameter rather than dereference ARGV
directly:
+my $input_fname = $ARGV[0];
+my $o
On 28.08.25 15:29, Daniel Gustafsson wrote:
On 28 Aug 2025, at 08:53, Peter Eisentraut wrote:
I addressed all those, and did another cleanup pass over the script. (The
formatting is from pgperltidy.)
A tiny nitpick is that all the other generator scripts (that I looked at) in
the tree
I've been trying out the Solaris compiler (Oracle Developer Studio 12.6,
on Solaris), mainly to test out some C11 support details. Observations:
- That compiler has a certain known idiosyncratic way of dealing with
some inline functions, which lead to commits such as 3e9ca526012 and
discussio
e-arranging the code a bit.
The other two indicate more fundamental problems. The gist API uses
these arguments to pass back information; these pointers do not in fact
point to a const object.
This possibly means that the change
commit c8b2ef05f48
Author: Peter Eisentraut
Date: Tue Sep 27
On 03.07.25 18:01, Daniel Gustafsson wrote:
On 2 Jul 2025, at 13:44, Peter Eisentraut wrote:
On 27.06.25 19:24, Daniel Gustafsson wrote:
The OpenSSL code in libpq have two issues for multithreading: the verify_cb
callback use a global variable to pass back error detail state and there is one
On 23.08.25 08:09, Peter Eisentraut wrote:
meson.build files have to list TAP test files explicitly. Makefiles
have been relying on a t/*.pl wildcard. As a consequence, it is
traditional now that many developers who are primarily using make forget
to add any new TAP test files to the
On 31.08.25 16:34, Tom Lane wrote:
I think our past practice has been to list any one item either in
Migration or the following sections, not in both places. This item
seems to adhere to that too: I don't see that commit hash anywhere
else. So I'm not clear why you're finding this duplicative?
On 30.08.25 18:52, Tom Lane wrote:
Bruce Momjian writes:
Second, the release note item added by this commit:
commit d1073c3b4cc
Author: Peter Eisentraut
Date: Fri Aug 29 10:18:10 2025 +0200
Unfortunately src/tools/add_commit_links.pl can't process the
and t
deeper
efforts to untangle header files, with the help of IWYU. But that is a
separate project.)
From 9cca8a11e0c5107cc4577cd0d14c79a3cd154d62 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 29 Aug 2025 13:18:50 +0200
Subject: [PATCH 1/7] Improve pgbench definition of yyscan_t
On 26.08.25 18:52, Heikki Linnakangas wrote:
So maybe the release notes should say
"now observes the locale provider configured for the database to
convert strings to lower case".
Is it only used for converting to lower case, or is there any other
operations that need to be mentioned? Converti
On 07.08.25 16:58, Tom Lane wrote:
Peter Eisentraut writes:
Attached are three patches to fix some unrelated problems with
headerscheck in my environment.
0001 seems fine; it's an oversight that I'd not noticed because
ICU_CFLAGS is empty in my usage.
committed
Don't
On 28.08.25 04:27, Chao Li wrote:
On Aug 27, 2025, at 17:24, Peter Eisentraut wrote:
This style of having Foo be a type alias for pointer-to-FooData is an
ancient Postgres coding convention that does not map well to modern C
that has an emphasis on judicious use of qualifiers and attributes
On 28.08.25 10:08, Kirill Reshke wrote:
On Sat, 23 Aug 2025 at 19:57, Peter Eisentraut wrote:
On 22.08.25 11:59, Álvaro Herrera wrote:
On 2025-Aug-22, Kirill Reshke wrote:
I am uncertain about the delineation between when we make changes and
when we refrain from doing so.
I think this is
On 26.08.25 18:21, Heikki Linnakangas wrote:
+1 for the comment patch (0001-Improve-objectNamesToOids-comment.patch).
+1 for also doing something like (0002-WIP-Attempt-to-put-back-intra-
grant-inplace.spec-cov.patch), to keep the test coverage for the "cache
lookup failed" error. Maybe add a
On 25.08.25 04:43, Chao Li wrote:
Can we avoid the duplication in a way like:
```
static int
func_lookup_failure_details(int fgc_flags, List *argnames, bool proc_call)
{
const char *func_kind = proc_call ? "procedure" : "function";
/*
if (proc_call)
retur
On 24.08.25 20:47, Tom Lane wrote:
Here is a v4 with some additional bike-shedding on the error texts.
In particular, I decided that it was worth expending an additional
flag bit so that we could reliably distinguish "There is no function
of that name" from "A function of that name exists, but it
On 27.08.25 14:39, Matheus Alcantara wrote:
On Tue Aug 26, 2025 at 3:26 AM -03, Dilip Kumar wrote:
On Tue, Aug 26, 2025 at 11:31 AM Dilip Kumar wrote:
On Sun, Aug 24, 2025 at 5:59 PM Srinath Reddy Sadipiralla
wrote:
Hi,
Thanks Dilip and Matheus for working on this , i reviewed the
latest p
On 27.08.25 10:57, Chao Li wrote:
This is a pure refactor patch.
The functions LockTuple, ConditionalLockTuple, UnlockTuple, and
XactLockTableWait take an ItemPointer parameter named 'tid'. Since these
functions do not modify the tuple identifier, the parameter should be
declared as const to
On 22.08.25 07:09, Michael Paquier wrote:
An extra thing is a suggested change for pg_nextpower2_32(), to use a
uint64 instead of a uint32 as argument, which is caused by
next_pow2_int64() and next_pow2_int(), that both used int64
previously.
That seems highly confusing. What is the meaning of
On 30.07.25 00:11, David Rowley wrote:
On Wed, 30 Jul 2025 at 00:57, Tom Lane wrote:
David Rowley writes:
On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut wrote:
Note that gcc and clang switched to C11 by default a long time ago
(gcc-5 and clang-3.6), so for most users all these tests won&#
On 22.08.25 11:59, Álvaro Herrera wrote:
On 2025-Aug-22, Kirill Reshke wrote:
I am uncertain about the delineation between when we make changes and
when we refrain from doing so.
I think this is natural work after 9c727360bcc7, before which
BufferGetPage() was a macro and strangely enough had
:00 2001
From: Peter Eisentraut
Date: Sat, 23 Aug 2025 08:00:09 +0200
Subject: [PATCH] List TAP test files in makefiles
meson.build files have to list TAP test files explicitly. Makefiles
have been relying on a t/*.pl wildcard. As a consequence many
developers that are primarily using make forget t
Committed.
Note that the proposed commit message had an example using ALTER TABLE,
which was not right. I used an example from your email using ALTER
DOMAIN instead.
On 13.05.25 11:34, wenhui qiu wrote:
HI
Thanks for the patch! and overall this is a valuable improvement in
terms of co
On 08.08.25 22:07, Andres Freund wrote:
On 2025-08-05 19:20:20 +0200, Peter Eisentraut wrote:
On 31.07.25 19:17, Tom Lane wrote:
Also I see a "// XXX" in pg_get_aios, which I guess is a note
to confirm the data type to use for ioh_id?
Yes, the stuff returned from pgaio_io_get_id()
On 16.07.25 14:01, Euler Taveira wrote:
There is an old thread [1] that proposed $SUBJECT. That patch was not committed
and the thread died. I use the referred patch as base for the attached version.
The key differences between them are: documentation, tests, refactor (0001) and
a few cleanups
On 15.04.25 11:02, Daniel Gustafsson wrote:
On 15 Apr 2025, at 10:52, jian he wrote:
in refuseDupeIndexAttach, we can change from
errdetail("Another index is already attached for partition \"%s\"."...)
to
errdetail("Another index \"%s\" is already attached for partition \"%s\".")
So we ca
On 18.08.25 15:27, Andres Freund wrote:
On 2025-07-18 14:12:34 +0300, Peter Eisentraut wrote:
I also moved the test a bit earlier in meson.build, as a separate patch,
because between the place where the compiler is first set up and the place
where we detected the C99 options, if any, there were
On 19.08.25 08:24, Michael Paquier wrote:
While looking at the recent business with dynahash.c in [1], I have
been reminded of the fact that this code still depends on long.
It's definitely a good idea to get rid of "long" usage. But you can
also replace it with long long instead of int64. I
On 09.07.25 01:28, Michael Paquier wrote:
On Tue, Jul 08, 2025 at 05:40:39PM +0300, Florents Tselai wrote:
On Tue, Jul 1, 2025 at 12:25 PM Peter Eisentraut wrote:
+
+Below are some checklists for common scenarios.
+
+## Adding a New Built-in SQL Command
+
+1. Implement the function in C and
On 09.12.24 11:11, Peter Eisentraut wrote:
lowerstr() and lowerstr_with_len() in ts_locale.c do the same thing as
str_tolower(), except that the former don't use the common locale
provider framework but instead use the global libc locale settings.
This patch replaces uses of lowerstr*()
On 13.12.24 09:57, Alexander Kuznetsov wrote:
Hello, ping?
24.09.2024 17:52, Alexander Kuznetsov wrote:
Hello,
is there anything else we can help with or discuss in order to apply
this fix?
24.07.2024 18:53, Alexander Kuznetsov пишет:
24.07.2024 18:39, Peter Eisentraut wrote:
If it
On 01.04.25 16:19, Andrew Jackson wrote:
Added some tests for the LDAP connection parameters lookup functionality
with the attached patch. It is based off of the tests that were added
recently that cover the connection service file libpq functionality as
well as the existing ldap test framework
On 12.08.25 21:48, Tom Lane wrote:
PFA v2 with these changes. I feel like this is pretty close to
committable now.
This looks good to me.
One additional comment: In network.c and varlena.c there are a couple of
comments that match /4 byte datum/ that talk about abbreviation support
in that
On 08.05.25 09:18, Noboru Saito wrote:
3. **Replaced `text-indent` with `margin-left` for `func_signature` and
`column_definition`**:
- The previous `text-indent: -3.5em` only affected the first line, causing
inconsistent formatting for multi-line code blocks. Changing this to
`margin-left: 0em`
On 08.05.25 09:18, Noboru Saito wrote:
### Patch 2: Adjustments to table column widths
Building on the first patch, the second patch adjusts the column widths of
various tables in the documentation to take advantage of the increased
display width.
I have committed this, except the change in ta
On 26.06.25 08:47, Tatsuo Ishii wrote:
Dear Kuroda-san,
Dear Ishii-san,
Actually Saito-san has already been registered [1]. And cfbot said OK.
[1]: https://commitfest.postgresql.org/patch/5775/
Thank you for pointing it out. Also I see Peter has been already
registered as a committer. Great
On 12.08.25 06:57, John Naylor wrote:
Before getting to that, I thought I'd bring this up to the community:
+# Copyright (C) 2000-2009, International Business Machines
Corporation and others.
+# All Rights Reserved.
The previous XML file didn't contain a copyright notice -- does anyone
want to
On 12.08.25 17:46, Jacob Champion wrote:
On Tue, Aug 12, 2025 at 8:37 AM Peter Eisentraut wrote:
The whole thing is puzzling, since we use the same code in the backend,
without any Windows-specific guards. No clue.
I think it's a CI-wide failure, or at least the cfbot is showing
On 12.08.25 18:37, Jacob Champion wrote:
On Tue, Aug 12, 2025 at 9:27 AM Tom Lane wrote:
Is there a way to work around this problem in a way that affects Windows only?
Even on Windows, the proposal is unacceptable.
Sure, but I'm hoping that there's some Windows-specific Meson
twiddling that
On 23.05.25 13:51, Peter Eisentraut wrote:
On 15.05.25 14:54, Pavel Seleznev wrote:
I applied your patch. I ran extended application tests relative to
vanilla ones, which include various scenarios of working with LDAP and
I think that we can safely apply the patch in the PG18.
I did not see
On 09.08.25 18:44, Tom Lane wrote:
I've now fleshed out the patch series with some cleanup of code that's
been rendered dead.
These patches look mechanically correct to me.
For patch 0002:
The various additional uses of *GetDatum and DatumGet* could be applied
as a separate patch. That woul
I have browsed this patch set a bit to get myself up to date.
General thoughts:
This is a large patch set, and it's not going to be perfect at the first
try. Especially, some of the parsing rules, query semantics, that kind
of thing. So I'm thinking that we should aim at integrating this wit
be to make this work so that most of guc_tables.c is
generated, and nothing else changes beyond that. But before I do all
the remaining tedious work, I wanted to check what people think.From 31e00a9282e154c62197e1bbceeb328e0e088110 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 11 Au
trying to clean up the initialization code a bit first.)
From 4044c8613be343ad4431d42c16d6b190c97e2b35 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sat, 9 Aug 2025 18:27:30 +0200
Subject: [PATCH] plpython: Remove support for major version conflict detection
This essentially reverts com
On 08.08.25 22:30, Andres Freund wrote:
One thing that would be an interesting follow-up would be to make the struct
not just carry the datum, but also the type of the field, to be filled in by
tuple deforming and the *GetDatum() functions. Then we could assert that the
correct DatumGet*() functi
On 08.08.25 22:55, Tom Lane wrote:
FWIW, I don't love the "DummyDatum" name either. Maybe InvalidDatum?
I specifically did not use InvalidDatum because, for example, the result
of Int32GetDatum(0) is by no means "invalid". Maybe something like
NullDatum or VoidDatum?
A few related thought
On 26.06.25 17:10, Matheus Alcantara wrote:
On Wed Jun 25, 2025 at 3:07 PM -03, Alexander Pyhalov wrote:
Matheus Alcantara писал(а) 2025-06-25 14:36:
Hi, thanks for testing and reporting the issue!
On 25/06/25 11:37, Alexander Pyhalov wrote:
Hi.
I've started to look at this feature and found
On 07.08.25 03:55, Tom Lane wrote:
I wrote:
I think that on a 32-bit machine this would actually result in a
null-pointer core dump, since the 0.0 would be coerced to a zero
Datum value. The line is not reached in our regression tests,
and given the lack of field complaints, it must be hard to
On 06.08.25 21:11, Tom Lane wrote:
Peter Eisentraut writes:
On 05.08.25 20:09, Tom Lane wrote:
Curiously, no such complaints appear with cpluspluscheck (which is
using g++ 15.1.1). I don't really understand why not ...
-Wmissing-variable-declarations is added by us as of PG18 (c
On 05.08.25 20:09, Tom Lane wrote:
Curiously, no such complaints appear with cpluspluscheck (which is
using g++ 15.1.1). I don't really understand why not: why would
they have turned on -Wmissing-variable-declarations by default
for C but not C++? But anyway, since there doesn't seem to be
any
On 06.08.25 20:06, Nathan Bossart wrote:
On Wed, Aug 06, 2025 at 12:09:28PM -0500, Nathan Bossart wrote:
On Tue, Aug 05, 2025 at 09:20:09PM -0500, Nathan Bossart wrote:
That explains it. I didn't find any past discussions about this particular
name, but commit de160e2 was being developed concu
On 05.08.25 20:06, Peter Eisentraut wrote:
> diff --git a/src/backend/utils/adt/timestamp.c b/src/backend/utils/
adt/timestamp.c
> index 25cff56c3d0..e640b48205b 100644
> --- a/src/backend/utils/adt/timestamp.c
> +++ b/src/backend/utils/adt/timestamp.c
> @@
ntext:
[0]:
https://www.postgresql.org/message-id/8246d7ff-f4b7-4363-913e-827dadfeb145%40eisentraut.orgFrom 11eb6931c0903ebac40efd95cda201f341bec59b Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 6 Aug 2025 12:20:44 +0200
Subject: [PATCH 1/2] Improve test coverage of date_trunc() on inf
On 05.08.25 08:22, Chao Li wrote:
I agree with Tom that we may just redefine GB18030 to comply with the
2022 standard.
As John Naylor pointed, 2022 is not backward compatible, that is true.
However, I went through all the incompatible changes, those are all
characters rarely used. So I would
On 04.08.25 05:03, Thomas Munro wrote:
On Sun, Aug 3, 2025 at 6:25 AM Nathan Bossart wrote:
On Sat, Aug 02, 2025 at 11:09:16AM +0200, Peter Eisentraut wrote:
These were introduced (commit efdc7d74753) at the same time as we were
moving to using the standard inttypes.h format macros (commit
> diff --git a/src/backend/utils/adt/timestamp.c
b/src/backend/utils/adt/timestamp.c
> index 25cff56c3d0..e640b48205b 100644
> --- a/src/backend/utils/adt/timestamp.c
> +++ b/src/backend/utils/adt/timestamp.c
> @@ -4954,7 +4954,7 @@ timestamptz_trunc_internal(text *units,
TimestampTz timestamp,
On 01.08.25 19:17, Tomas Vondra wrote:
On 7/31/25 20:35, Tom Lane wrote:
Tomas Vondra writes:
On 7/31/25 19:33, Tom Lane wrote:
... It is certainly broken on
32-bit machines where the Datum result of numeric_float8 will
be a pointer, so that we will convert the numeric pointer value
to a fl
patch that tries to straighten that out by using int consistently and -1
as a special marker.
From e1bb97e13af226cd15c9a59929aef48bc92c4ac2 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 5 Aug 2025 19:16:38 +0200
Subject: [PATCH] Use consistent type for pgaio_io_get_id() result
The
On 03.08.25 22:20, Tom Lane wrote:
It looks like the majority vote is still in favor of writing out
DatumGetPointer instead of using "_D()" functions, so let's roll
with that approach.
I looked through our two versions of the varatt.h changes and
merged them. The attached is only cosmetically d
On 31.07.25 09:24, Nazir Bilal Yavuz wrote:
On Wed, 30 Jul 2025 at 21:56, Peter Eisentraut wrote:
On 30.07.25 12:58, Nazir Bilal Yavuz wrote:
That makes sense. I noticed one difference, patched prep_buildtree
does not create a symbolic link for the top Makefile in the builddir.
Ok, here
e the callers use PRIx64.
(Also, INT64_HEX_FORMAT was kind of a misnomer, since hex formats all
use unsigned types.)
[should be backpatched to PG18]From 6cb3bd4b86d35d9ba67c0d8bbf1ed1fc76b07a5e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sat, 2 Aug 2025 10:35:50 +0200
Subject: [PATCH] R
On 29.07.25 11:46, David Rowley wrote:
../src/backend/parser/gram.y:19362:12: error: call to undeclared
function 'typeof'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
19362 | result = copyObject(p->argType);
It's not quite c
On 18.07.25 02:09, Tom Lane wrote:
The attached patch switches to 8-byte Datums everywhere, but
doesn't make any effort to remove the now-dead code.
Is the plan to support only exactly Datums of size 8, or Datums of size
at least 8?
There are some optimistic conditionals like
#if SIZEOF_DAT
On 30.07.25 18:06, Tom Lane wrote:
Right, we have for a long time not worried about whether VARDATA and
the allied macros are being fed a pointer or a Datum. I recall that
somebody tried to make those macros into static inlines awhile back,
and failed because of the lack of clarity about how to
On 18.07.25 18:26, Andres Freund wrote:
One of these days I should again try the experiment of making Datum into a
struct, to automatically catch omissions of datum <-> native type. Having them
be silent most of the time really sucks. I suspect that if we get the
64bit-datum-on-32bit-platform cod
ge-id/flat/1749799.1752797397%40sss.pgh.pa.usFrom fb4036e3ea593fe3d6f0791793cc9e282226783d Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 31 Jul 2025 14:54:16 +0200
Subject: [PATCH v1 1/2] Fix varatt versus Datum type confusions
Macros like VARDATA() and VARSIZE() should be thought of as tak
On 30.07.25 18:13, Jacob Champion wrote:
On Wed, Jul 30, 2025 at 4:09 AM Peter Eisentraut wrote:
The POSIX description of getentropy() says:
"The intended use of this function is to create a seed for other
pseudo-random number generators."
So using getentropy() for generating
On 30.07.25 12:58, Nazir Bilal Yavuz wrote:
Hi,
On Wed, 30 Jul 2025 at 12:32, Peter Eisentraut wrote:
On 30.07.25 10:28, Nazir Bilal Yavuz wrote:
On Wed, 30 Jul 2025 at 11:07, Peter Eisentraut wrote:
To fix this, I first tried to devise a way to detect whether a given
directory is a
On 30.07.25 13:55, Daniel Gustafsson wrote:
The point still stands that the number of installations without OpenSSL support
is approximately zero, so what is the purpose of this patch if approximately no
one will be able to use it?
The main usecase I've heard discussed (mostly in hallway tra
On 30.07.25 08:59, Masahiko Sawada wrote:
I've updated the patch to support getentropy() instead of getrandom().
The point still stands that the number of installations without OpenSSL
support is approximately zero, so what is the purpose of this patch if
approximately no one will be able to
On 22.07.25 13:11, Dagfinn Ilmari Mannsåker wrote:
getrandom() is Linux-specific, while getentropy() is specified by POSIX
(since 2024). It was originally introduced by OpenBSD 5.6 in 2014, and
was added to macOS 10.12 in 2016, glibc 2.25 (same as getrandom()) in
2017, musl 1.1.20 and FreeBSD 12
On 30.07.25 10:28, Nazir Bilal Yavuz wrote:
On Wed, 30 Jul 2025 at 11:07, Peter Eisentraut wrote:
To fix this, I first tried to devise a way to detect whether a given
directory is a build directory. But that seemed pretty complicated.
Instead, I chose the simpler solution that we just
you use meson.
From b9800a40d4f6e8c9339fd2ef91d058a1196ebc51 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 9 Jul 2025 15:45:01 +0200
Subject: [PATCH] Improve prep_buildtree
When prep_buildtree is used to prepare a build tree when the source
directory already contains another build tree, then
On 24.07.25 03:14, David Rowley wrote:
So, I think that means we can adjust the meson build scripts to pass
/std:c11 when building in MSVC. The attached patch does this and
defines a pg_builtin_constant() macro and adjusts ereport_domain() to
use it.
Please review my patch at
https://www.postg
hen the test should decide that it needs to add another option to
override the C mode.
From ee5fd55153d5f407b1062e2ce5ff741a7d503c44 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 18 Jul 2025 13:26:40 +0300
Subject: [PATCH v1 1/2] meson: Move C99 test earlier
That way, if any comma
On 16.07.25 01:35, Peter Geoghegan wrote:
On Sat, Jul 12, 2025 at 1:55 PM Andres Freund wrote:
I had played with using pg_assume here too, but I couldn't really convince
myself that it's a good idea...
In the past, it was often necessary to work around MSVC's inability to
see that a block con
On 07.07.25 16:13, Tom Lane wrote:
Nazir Bilal Yavuz writes:
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut wrote:
Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
never shown a problem like this.
CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm m
On 06.07.25 00:27, Tom Lane wrote:
Peter Eisentraut writes:
On 04.06.25 08:15, Peter Eisentraut wrote:
For an explanation, the background is that MSVC has a "traditional"
preprocessor and a new "conforming" one. The latter is available
starting in VS 2019, but it's
On 01.07.25 10:47, Daniel Gustafsson wrote:
On 29 Jun 2025, at 12:56, Peter Eisentraut wrote:
On 27.06.25 11:15, Daniel Gustafsson wrote:
On 26 Jun 2025, at 23:06, Daniel Gustafsson wrote:
I'll propose changes for these comments in the morning when coffee has been
had.
The attached mov
On 02.07.25 04:55, Jianghua Yang wrote:
While working with `initdb`, I noticed that passing an empty string to
the `-U` option (e.g., `initdb -U ''`) causes it to fail with a
misleading error:
performing post-bootstrap initialization ... 2025-07-01 19:48:42.006 PDT
[14888] FATAL:role """ does
On 27.06.25 19:24, Daniel Gustafsson wrote:
The OpenSSL code in libpq have two issues for multithreading: the verify_cb
callback use a global variable to pass back error detail state and there is one
use of strerror().
Slightly misleading title: This is actually about the *backend* libpq code.
On 02.07.25 09:22, Nazir Bilal Yavuz wrote:
One thing I’m unsure about the patch is that all these features are
stored in the MESON_FEATURES environment variable in each task. I
wonder if it might be clearer to rename these variables to
${TASK_NAME}_MESON_FEATURES to avoid confusion.
I would ho
On 30.06.25 05:21, Daniil Davydov wrote:
Hi,
I noticed that some asserts and cycles use magic numbers 1 and 0
instead of BTLessStrategyNumber and InvalidStrategy.
At the same time, the BTMaxStrategyNumber macro is used there.
I suggest using appropriate macros for 1 and 0 values.
This code, bot
On 22.06.25 15:12, Peter Eisentraut wrote:
On 19.06.25 14:24, Andres Freund wrote:
Along the way, I also found that our meson.build always issues a warning
when run on Windows/msvc, which I fixed. (Should probably be
backpatched.)
Agreed. Looks like that came in with bc46104fc9aa
I have
On 01.05.25 15:47, Japin Li wrote:
On Thu, 01 May 2025 at 12:13, Peter Eisentraut wrote:
On 30.04.25 17:48, Japin Li wrote:
While working on [1], I found outdated comments in IndexInfo.
The attached patch corrects them.
[1]
https://www.postgresql.org/message-id/2A40921D-83AB-411E-ADA6
On 02.07.25 09:01, John Naylor wrote:
On Tue, Jul 1, 2025 at 9:24 PM Tom Lane wrote:
Ha, indeed you are right. On my RHEL9 box, it's kinda drowned out
by complaints about
/usr/include/c++/11/bits/range_access.h:109:3: error: template with C linkage
109 | template _Tp* end(valarray<_Tp>&)
On 17.06.25 20:50, Dean Rasheed wrote:
On Tue, 17 Jun 2025 at 13:56, jian he wrote:
On Tue, Jun 17, 2025 at 7:42 PM Peter Eisentraut wrote:
However, I see your point that it contrasts with the attidentity code
just above.
Perhaps a way to resolve this would be to rewrite the comment
On 04.06.25 08:15, Peter Eisentraut wrote:
On 03.06.25 06:51, Michael Paquier wrote:
Dropping VS 2015 and going up to VS 2019 brings other benefits,
__VA_ARGS__ coming in mind.
Yes, this was going to be my next step. As we're already talking about
it, here is my proposed patch.
F
On 18.06.25 11:46, Bertrand Drouvot wrote:
Hi,
On Tue, Jun 17, 2025 at 07:21:13AM +0200, Peter Eisentraut wrote:
On 12.06.25 08:26, jian he wrote:
in contrib/amcheck/verify_heapam.c, check_tuple
report_corruption(ctx,
psprintf("number of attribut
On 24.05.25 12:34, Florents Tselai wrote:
On 24 May 2025, at 12:24 PM, Álvaro Herrera wrote:
On 2025-May-24, Florents Tselai wrote:
I aggree with having more READMEs around the src tree.
It’s true that a lot of doc content found in VII. Internals is dev-oriented,
but imho it should be clos
On 16.01.25 06:38, Peter Smith wrote:
On Thu, Jan 16, 2025 at 3:26 PM Tom Lane wrote:
Peter Smith writes:
During some recent reviews, I came across some comments mentioning "toast" ...
TOAST is a PostgreSQL acronym for "The Oversized-Attribute Storage
Technique" [1].
It is indeed an acrony
On 17.06.25 07:15, Peter Eisentraut wrote:
On 28.05.25 20:42, J. Javier Maestro wrote:
On Wed, May 28, 2025 at 6:08 PM Andres Freund <mailto:and...@anarazel.de>> wrote:
Hi,
On 2025-05-17 23:32:24 -0400, J. Javier Maestro wrote:
> On Tue, May 13, 2025 at 11:54 AM A
On 16.06.25 16:20, Aleksander Alekseev wrote:
The removals of bother me a bit; I believe those used
to be necessary on some platforms. Maybe nowadays everybody is
close enough to POSIX that you can safely extrapolate from what
clangd says on your own machine, but it's not zero-risk.
Sounds go
1 - 100 of 2366 matches
Mail list logo
