Re: Upgrade Debian CI images to Bookworm

On 13.05.24 12:57, Nazir Bilal Yavuz wrote: Bookworm versions of the Debian CI images are available now [0]. The patches to use these images are attached. 'v1-0001-Upgrade-Debian-CI-images-to-Bookworm_REL_16+.patch' patch can be applied to both upstream and REL_16 and all of the tasks finish

Re: Convert node test compile-time settings into run-time parameters

till needs to be maintained by hand, so it's more often valuable to have it checked automatically. From 80f35c90e3414dabd879e8832ce1b89c685e5de5 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Fri, 24 May 2024 11:42:02 +0200 Subject: [PATCH v2] Convert node test compile-time settings int

Re: AIX support

On 22.05.24 18:15, Sriram RK wrote: Please find the attached patch. Apart from the AIX specific changes, there is a minor change in this file wrt to XLC, below is the error for which we removed inline. Later, the build and tests passed for both XLC(16.1.0.18) and gcc(12) as well. I think

Re: Virtual generated columns

On 29.04.24 20:54, Corey Huinker wrote:  -- generation expression must be immutable -CREATE TABLE gtest_err_4 (a int PRIMARY KEY, b double precision GENERATED ALWAYS AS (random()) STORED); +CREATE TABLE gtest_err_4 (a int PRIMARY KEY, b double precision GENERATED ALWAYS AS

Re: Schema variables - new implementation for Postgres 15

On 18.05.24 13:29, Alvaro Herrera wrote: I want to note that when we discussed this patch series at the dev meeting in FOSDEM, a sort-of conclusion was reached that we didn't want schema variables at all because of the fact that creating a variable would potentially change the meaning of queries

Re: Pgoutput not capturing the generated columns

On 08.05.24 09:13, Shubham Khanna wrote: The attached patch has the changes to support capturing generated column data using ‘pgoutput’ and’ test_decoding’ plugin. Now if the ‘include_generated_columns’ option is specified, the generated column information and generated column data also will be

Re: tydedef extraction - back to the future

On 20.05.24 23:11, Andrew Dunstan wrote: Attached is an attempt to thread this needle. The core is a new perl module that imports the current buildfarm client logic. The intention is that once we have this, the buildfarm client will switch to using the module (if found) rather than its own

Re: in parentesis is not usual on DOCs

On 20.05.24 02:00, jian he wrote: removing parentheses means we need to rephrase this sentence? So I come up with the following rephrase: The context_item specifies the input data to query, the path_expression is a JSON path expression defining the query, json_path_name is an optional name for

Re: Convert node test compile-time settings into run-time parameters

On 20.05.24 15:59, Tom Lane wrote: Peter Eisentraut writes: This patch converts the compile-time settings COPY_PARSE_PLAN_TREES WRITE_READ_PARSE_PLAN_TREES RAW_EXPRESSION_COVERAGE_TEST into run-time parameters debug_copy_parse_plan_trees

Re: Speed up clean meson builds by ~25%

On 19.05.24 00:09, Andres Freund wrote: On 2024-05-18 00:35:08 +0200, Peter Eisentraut wrote: I retested the patch from 2024-04-07 (I think that's the one that "fixed that"? There are multiple "v1" patches in this thread.) using gcc-14 and clang-18, with ccach

Convert node test compile-time settings into run-time parameters

? Another thought: Do we really need three separate settings? From 568c620eb97f82aa8eab850cb3ce703c5c94a912 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 20 May 2024 09:13:23 +0200 Subject: [PATCH v1] Convert node test compile-time settings into run-time parameters This converts

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

On 19.05.24 20:07, David Benjamin wrote: On Sun, May 19, 2024 at 12:21 PM Tom Lane > wrote: Per the cfbot [1], this patch needs a rebase over the ALPN-related commits.  It still isn't likely to get human attention before the July commitfest, but you can

Re: Speed up clean meson builds by ~25%

On 17.05.24 23:01, Robert Haas wrote: On Fri, May 17, 2024 at 4:59 PM Tom Lane wrote: As I mentioned upthread, I'm more worried about confusing error reports than the machine time. Well, Jelte fixed that. I grant that there are people who are more affected, but still, I'd just as soon not

Re: commitfest.postgresql.org is no longer fit for purpose

On 17.05.24 14:42, Joe Conway wrote: Namely, the week before commitfest I don't actually know if I will have the time during that month, but I will make sure my patch is in the commitfest just in case I get a few clear days to work on it. Because if it isn't there, I can't take advantage of

Re: commitfest.postgresql.org is no longer fit for purpose

On 17.05.24 09:32, Heikki Linnakangas wrote: Dunno about having to click a link or sparkly gold borders, but +1 on having a free-form text box for notes like that. Things like "cfbot says this has bitrotted" or "Will review this after other patch this depends on". On the mailing list, notes

Re: commitfest.postgresql.org is no longer fit for purpose

On 17.05.24 13:36, Daniel Gustafsson wrote: On 17 May 2024, at 13:13, Robert Haas wrote: But if we are to guess what those reasons might be, Tom has already admitted he does that for CI, and I do the same, so probably other people also do it. I also suspect that some people are essentially

Re: GUC names in messages

On 17.05.24 05:31, Peter Smith wrote: I think we should accept your two patches v6-0001-GUC-names-docs.patch v6-0002-GUC-names-add-quotes.patch which effectively everyone was in favor of and which seem to be the most robust and sustainable solution. (The remaining three patches from the v6

Re: Ignore Visual Studio's Temp Files While Working with PG on Windows

On 17.05.24 08:09, Yasir wrote: I have been playing with PG on the Windows platform recently. An annoying thing I faced is that a lot of Visual Studio's temp files kept appearing in git changed files. Therefore, I am submitting this very trivial patch to ignore these temp files. Our general

Re: Minor cleanups in the SSL tests

On 16.05.24 23:27, Daniel Gustafsson wrote: On 16 May 2024, at 11:43, Peter Eisentraut wrote: You might want to run your patch through pgperltidy. The result doesn't look bad, but a bit different than what you had crafted. Ugh, I thought I had but clearly had forgotten. Fixed now

Re: Why does pgindent's README say to download typedefs.list from the buildfarm?

On 16.05.24 16:45, Tom Lane wrote: Peter Eisentraut writes: In these cases, I think for NotificationHash ResourceOwnerData WalSyncMethod we can just get rid of the typedef. I have no objection to dealing with NotificationHash as you have here. ReadBuffersFlags shouldn't be an enum at all

Re: commitfest.postgresql.org is no longer fit for purpose

On 17.05.24 04:26, Robert Haas wrote: I do*emphatically* think we need a parking lot. People seem to like this idea; I'm not quite sure I follow it. If you just want the automated patch testing, you can do that on your own by setting up github/cirrus for your own account. If you keep

Re: commitfest.postgresql.org is no longer fit for purpose

On 17.05.24 00:13, Tom Lane wrote: So a third status that encompasses the various other situations like maybe forgotten by author, disagreements between author and reviewer, process difficulties, needs some senior developer intervention, etc. could be helpful. Hmm, "forgotten by author" seems

Re: commitfest.postgresql.org is no longer fit for purpose

On 16.05.24 23:46, Tom Lane wrote: Peter Eisentraut writes: The problem is if we have 180 patches in Needs Review, and only 20 are really actually ready to be reviewed. And a second-order problem is that if you already know that this will be the case, you give up before even looking. Right

Re: commitfest.postgresql.org is no longer fit for purpose

On 16.05.24 23:06, Joe Conway wrote: On 5/16/24 16:57, Jacob Champion wrote: On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote: Maybe we should just make it a policy that *nothing* gets moved forward from commitfest-to-commitfest and therefore the author needs to care enough to register for

Re: commitfest.postgresql.org is no longer fit for purpose

On 16.05.24 23:04, Tom Lane wrote: I think it'd be great if we could separate "I'm actively reviewing this" from "I'm interested in this". As a bonus, adding yourself to the "interested" list would be a fine proxy for the thumbs-up or star markers mentioned upthread. If those were separate

Re: commitfest.postgresql.org is no longer fit for purpose

On 16.05.24 22:46, Melanie Plageman wrote: I was reflecting on why a general purpose patch tracker sounded appealing to me, and I realized that, at least at this time of year, I have a few patches that really count as "waiting on author" that I know I need to do additional work on before they

avoid MERGE_ACTION keyword?

use similar treatment. Thoughts?From 6e0132ca3f3472fb6c5f8c5b2ec7296de1f83811 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Thu, 16 May 2024 16:09:57 +0200 Subject: [PATCH] WIP: Avoid MERGE_ACTION keyword --- src/backend/parser/gram.y | 12 +- src/backend/parser/parse_expr.c

Re: Adding the extension name to EData / log_line_prefix

On 15.05.24 17:50, Tom Lane wrote: We kind of already have something like this, for NLS. If you look for pg_bindtextdomain(TEXTDOMAIN) and ereport_domain(), this information already trickles into the vicinity of the error data. Maybe the same thing could just be used for this, by wiring up the

Re: GUC names in messages

On 04.01.24 07:53, Peter Smith wrote: Now that I read this again, I think this is wrong. We should decide the quoting for a category, not the actual content. Like, quote all file names; do not quote keywords. This led to the attempted patch to decide the quoting of GUC parameter names

Re: [PATCH] Add --syntax to postgres for SQL syntax checking

On 15.05.24 21:05, Robert Haas wrote: I don't think it's at all obvious that this belongs on the server side rather than the client side. I think it could be done in either place, or both. I just think we don't have the infrastructure to do it cleanly, at present. I think if you're going to do

Re: An improved README experience for PostgreSQL

On 15.05.24 21:34, Nathan Bossart wrote: On Wed, May 15, 2024 at 07:23:19AM +0200, Peter Eisentraut wrote: I think for CONTRIBUTING.md, a better link would be <https://www.postgresql.org/developer/>. WFM This patch version looks good to me.

Re: Why does pgindent's README say to download typedefs.list from the buildfarm?

On 16.05.24 01:32, Tom Lane wrote: As for the remainder, they aren't showing up because no variable or field is declared using them, which means no debug symbol table entry is made for them. This means we could just drop those typedefs and be little the worse off notationally. I experimented

Re: Minor cleanups in the SSL tests

On 16.05.24 09:24, Daniel Gustafsson wrote: When writing a new SSL test for another patch it struck me that the SSL tests are doing configuration management without using the test framework API's. The attached patches cleans this up, no testcases are altered as part of this. 0001 makes the

Re: SQL:2011 application time

On 15.05.24 11:39, Peter Eisentraut wrote: Attached are the individual revert patches.  I'm supplying these here mainly so that future efforts can use those instead of the original patches, since that would have to redo all the conflict resolution and also miss various typo fixes etc

Re: Underscore in positional parameters?

On 16.05.24 01:11, Michael Paquier wrote: On Wed, May 15, 2024 at 01:59:36PM +0200, Peter Eisentraut wrote: On 14.05.24 18:07, Erik Wienhold wrote: Patch 0002 replaces atol with pg_strtoint32_safe in the backend parser and strtoint in ECPG. This fixes overflows like: Seems like a good idea

Re: Adding the extension name to EData / log_line_prefix

On 14.05.24 01:11, Tom Lane wrote: The mechanism that Andres describes for sourcing the name seems a bit overcomplex though. Why not just allow/require each extension to specify its name as a constant string? We could force the matter by redefining PG_MODULE_MAGIC as taking an argument:

Re: cataloguing NOT NULL constraints

for constraints on relations. I think the release notes don't properly address the ones on domains. I think it's at least these two commits: -Author: Peter Eisentraut -2024-03-20 [e5da0fe3c] Catalog domain not-null constraints -Author: Peter Eisentraut -2024-04-15 [9895b35cb] Fix ALTER DOMAIN

Re: Underscore in positional parameters?

On 14.05.24 18:07, Erik Wienhold wrote: Patch 0001 changes rules param and param_junk to only accept digits 0-9. I have committed this patch to PG16 and master. I was a little bit on the fence about what the behavior should be, but I checked Perl for comparison: print 1000; # ok print

Re: doc: some fixes for environment sections in ref pages

On 13.05.24 13:02, Daniel Gustafsson wrote: On 13 May 2024, at 10:48, Peter Eisentraut wrote: Patches attached. All patches look good. I think the first one is a bug fix. Agreed. Committed, thanks.

Re: Postgres and --config-file option

On 15.05.24 04:07, Michael Paquier wrote: Not sure that these additions in --help or the docs are necessary. The rest looks OK. -"You must specify the --config-file or -D invocation " +"You must specify the --config-file (or equivalent -c) or -D invocation " How about "You must specify

Re: pgsql: Fix overread in JSON parsing errors for incomplete byte sequence

On 15.05.24 02:00, Michael Paquier wrote: On Tue, May 14, 2024 at 10:39:36AM +0200, Peter Eisentraut wrote: I saw the same thing. The problem is that there is incomplete dependency information in the makefiles (not meson) between src/common/ and what is using it. So whenever anything changes

Re: An improved README experience for PostgreSQL

On 14.05.24 19:33, Nathan Bossart wrote: On Tue, May 14, 2024 at 06:12:26PM +0200, Alvaro Herrera wrote: On 2024-May-14, Tom Lane wrote: I don't have a position on whether we want these additional files or not; but if we do, I think the best answer is to stick 'em under .github/ where they

Re: Requiring LLVM 14+ in PostgreSQL 18

On 15.05.24 06:21, Thomas Munro wrote: And as I'm looking up how this was previously handled, I notice that this list of clang-NN versions was last updated equally sneakily as part of your patch to trim off LLVM <10 (820b5af73dc). I wonder if the original intention of that configure code was

Re: pgsql: Fix overread in JSON parsing errors for incomplete byte sequence

On 10.05.24 14:23, Alvaro Herrera wrote: On 2024-May-10, Alvaro Herrera wrote: Not sure what's going on here, or why it fails for me while the buildfarm is all happy. Ah, I ran 'git clean -dfx' and now it works correctly. I must have had an incomplete rebuild. I saw the same thing. The

Re: An improved README experience for PostgreSQL

On 13.05.24 17:26, Nathan Bossart wrote: On Sun, May 12, 2024 at 05:17:42PM +0200, Peter Eisentraut wrote: I don't know, I find these files kind of "yelling". It's fine to have a couple, but now it's getting a bit much, and there are more that could be added. I'm not sure wha

Re: An improved README experience for PostgreSQL

On 13.05.24 17:43, Alvaro Herrera wrote: On 2024-May-13, Nathan Bossart wrote: If we want to enhance the GitHub experience, we can also add these files to the organization instead:

Re: consider -Wmissing-variable-declarations

On 10.05.24 11:53, Heikki Linnakangas wrote: On 09/05/2024 12:23, Peter Eisentraut wrote: In [0] I had noticed that we have no automated verification that global variables are declared in header files.  (For global functions, we have this through -Wmissing-prototypes.)  As I mentioned there, I

Re: Large files for relations

On 06.03.24 22:54, Thomas Munro wrote: Rebased. I had intended to try to get this into v17, but a couple of unresolved problems came up while rebasing over the new incremental backup stuff. You snooze, you lose. Hopefully we can sort these out in time for the next commitfest: * should

Re: SQL:2011 application time

On 03.04.24 07:30, Paul Jungwirth wrote: But is it *literally* unique? Well two identical keys, e.g. (5, '[Jan24,Mar24)') and (5, '[Jan24,Mar24)'), do have overlapping ranges, so the second is excluded. Normally a temporal unique index is *more* restrictive than a standard one, since it

doc: some fixes for environment sections in ref pages

3f573c5935d46b20de7e7129cd0bf69abed1df6c Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 13 May 2024 10:10:21 +0200 Subject: [PATCH 1/3] doc: Remove claims that initdb and pg_ctl use libpq environment variables Erroneously introduced by 571df93cff8. --- doc/src/sgml/ref/initdb.sgml | 6

Re: Converting README documentation to Markdown

On 08.04.24 21:29, Daniel Gustafsson wrote: Over in [0] I asked whether it would be worthwhile converting all our README files to Markdown, and since it wasn't met with pitchforks I figured it would be an interesting excercise to see what it would take (my honest gut feeling was that it would be

Convert sepgsql tests to TAP

2f8e73932b1068caf696582487de9e100fcd46be Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 13 May 2024 07:55:55 +0200 Subject: [PATCH v1] Convert sepgsql tests to TAP Add a TAP test for sepgsql. This automates the previously required manual setup before the test. The actual tests are still run by pg_regress

Re: elog/ereport VS misleading backtrace_function function address

On 07.05.24 09:43, Jakub Wartak wrote: NOTE: in case one will be testing this: one cannot ./configure with --enable-debug as it prevents the compiler optimizations that actually end up with the ".cold" branch optimizations that cause backtrace() to return the wrong address. Is that

Re: An improved README experience for PostgreSQL

On 17.04.24 04:36, Nathan Bossart wrote: On Wed, Feb 28, 2024 at 02:21:49PM -0600, Nathan Bossart wrote: I see many projects have files like SECURITY.md, CODE_OF_CONDUCT.md, and CONTRIBUTING.md, and I think it would be relatively easy to add content to each of those for PostgreSQL, even if they

Re: Requiring LLVM 14+ in PostgreSQL 18

On 24.04.24 01:43, Thomas Munro wrote: Rebased over ca89db5f. These patches look fine to me. The new cut-off makes sense, and it does save quite a bit of code. We do need to get the Cirrus CI Debian images updated first, as you had already written. As part of this patch, you also sneak

Re: Logging which interface was connected to in log_line_prefix

On 01.05.24 19:04, Greg Sabino Mullane wrote: Thank you for taking the time to review this. I've attached a new rebased version, which has no significant changes. There is a comment in the patch that states: /* We do not need clean_ipv6_addr here: just report verbatim */ I am not

Re: Logging which interface was connected to in log_line_prefix

On 06.03.24 16:59, Greg Sabino Mullane wrote: Someone on -general was asking about this, as they are listening on multiple IPs and would like to know which exact one clients were hitting. I took a quick look and we already have that information, so I grabbed some stuff from inet_server_addr

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

On 19.04.24 11:47, Aleksander Alekseev wrote: Thanks. I see a few pieces of code that use special FOO_NUMBER enum values instead of a macro. Should we refactor these pieces accordingly? PFA another patch. I think this is a sensible improvement. But please keep the trailing commas on the last

Re: Build the docs if there are changes in docs and don't run other tasks if the changes are only in docs

On 14.12.23 14:40, Nazir Bilal Yavuz wrote: On Fri, 6 Oct 2023 at 17:07, Tom Lane wrote: As a quick cross-check, I searched our commit log to see how many README-only commits there were so far this year. I found 11 since January. (Several were triggered by the latest round of pgindent code

Re: Add TAP tests for backtrace functionality (was Re: Add test module for verifying backtrace functionality)

On 16.03.24 05:25, Bharath Rupireddy wrote: Postgres has a good amount of code for dealing with backtraces - two GUCs backtrace_functions and backtrace_on_internal_error, errbacktrace; all of which use core function set_backtrace from elog.c. I've not seen this code being tested at all, see code

Re: SQL:2011 application time

to e305f715, addressing Peter's feedback. I'm still working on integrating jian he's suggestions for the last patch, so I've omitted that one here. On 5/8/24 06:51, Peter Eisentraut wrote: About v2-0001-Fix-ON-CONFLICT-DO-NOTHING-UPDATE-for-temporal-in.patch, I think the ideas are right, but I wonder

consider -Wmissing-variable-declarations

practice. These should be organized into appropriate header files. [0]: https://www.postgresql.org/message-id/c4ac402f-9d7b-45fa-bbc1-4a5bf0a9f...@eisentraut.orgFrom 296a1c465de6cfea333bf7bb7950f02b3ef80b12 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Wed, 8 May 2024 13:49:37 +0200

Re: SQL:2011 application time

On 30.04.24 18:39, Paul Jungwirth wrote: On 4/30/24 09:24, Robert Haas wrote: Peter, could you have a look at http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com and express an opinion about whether each of those proposals are (a) good or bad ideas and (b) whether

Re: AIX support

On 08.05.24 13:39, Sriram RK wrote: We would like to understand your inputs/plans on reverting the changes for AIX. I think the ship has sailed for PG17. The way forward would be that you submit a patch for new, modernized AIX support for PG18.

Re: PERIOD foreign key feature

On 07.05.24 18:43, Paul Jungwirth wrote: On 5/7/24 08:23, David G. Johnston wrote: On Tue, May 7, 2024 at 7:54 AM Bruce Momjian > wrote:     In the two marked lines, it says "if one side of the foreign key uses     PERIOD, the other side must too."  However, looking at

Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall

On 03.05.24 19:13, Nathan Bossart wrote: This is likely small potatoes compared to some of the other pg_upgrade-related improvements I've proposed [0] [1] or plan to propose, but this is easy enough, and I already wrote the patch, so here it is. AFAICT there's no reason to bother syncing these

Re: partitioning and identity column

On 30.04.24 12:59, Ashutosh Bapat wrote: PFA patch which fixes all the three problems. I have committed this patch. Thanks all.

Re: wrong comment in libpq.h

On 04.05.24 00:29, David Zhang wrote: On 2024-05-03 4:53 a.m., Daniel Gustafsson wrote: On 3 May 2024, at 13:48, Peter Eisentraut wrote: Maybe it's easier if we just replaced     prototypes for functions in xxx.c with     declarations for xxx.c throughout src/include/libpq/libpq.h. +1 +1

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

On 03.05.24 10:39, Daniel Gustafsson wrote: I would recommend to update the documentation of PQinitSSL and PQinitOpenSSL to tell that these become useless and are deprecated. They are no-ops when linking against v18, but writing an extension which targets all supported versions of postgres

Re: Support LIKE with nondeterministic collations

On 03.05.24 17:47, Daniel Verite wrote: Peter Eisentraut wrote: However, off the top of my head, this definition has three flaws: (1) It would make the single-character wildcard effectively an any-number-of-characters wildcard, but only in some circumstances, which could be confusing

Re: Support LIKE with nondeterministic collations

On 03.05.24 16:58, Daniel Verite wrote: * Generating bounds for a sort key (prefix matching) Having sort keys for strings allows for easy creation of bounds - sort keys that are guaranteed to be smaller or larger than any sort key from a give range. For example, if bounds are

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On 03.05.24 16:13, Tom Lane wrote: Peter Eisentraut writes: On 30.04.24 19:29, Tom Lane wrote: Also, the bigger picture here is the seeming assumption that "if we change pg_trgm then it will be safe to replicate from x86 to arm". I don't believe that that's a good idea and I'm

Re: Support LIKE with nondeterministic collations

On 03.05.24 15:20, Robert Haas wrote: On Fri, May 3, 2024 at 4:52 AM Peter Eisentraut wrote: What the implementation does is, it walks through the pattern. It sees '_', so it steps over one character in the input string, which is '.' here. Then we have 'foo.' left to match in the input

Re: Document NULL

On 02.05.24 17:23, David G. Johnston wrote: Version 2 attached.  Still a draft, focused on topic picking and overall structure.  Examples and links planned plus the usual semantic markup stuff. I chose to add a new sect1 in the user guide (The SQL Language) chapter, "Data". Please, let's

Re: Tarball builds in the new world order

On 29.04.24 18:14, Tom Lane wrote: Peter Eisentraut writes: On 26.04.24 21:24, Tom Lane wrote: Concretely, I'm proposing the attached. Peter didn't like PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not wedded to that if a better name is proposed. This seems ok to me

Re: A failure in prepared_xacts test

On 29.04.24 07:11, Tom Lane wrote: Up to now, we've only worried about whether tests running in parallel within a single test suite can interact. It's quite scary to think that the meson setup has expanded the possibility of interactions to our entire source tree. Maybe that was a bad idea and

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On 30.04.24 19:29, Tom Lane wrote: 1) Assume that char signedness is somehow a property of bits-on-disk even though it's weird. Then pg_trgm indexes are correct, but we need to store char signedness in pg_control. 2) Assume that char signedness is not a property of bits-on-disk. Then pg_trgm

Re: [PATCH] json_lex_string: don't overread on bad UTF8

On 30.04.24 19:39, Jacob Champion wrote: Tangentially: Should we maybe rethink pieces of the json_lex_string error handling? For example, do we really want to echo an incomplete multibyte sequence once we know it's bad? I can't quite find the place you might be looking at in

Re: wrong comment in libpq.h

On 03.05.24 00:37, David Zhang wrote: Hi Hackers, There is a comment like below in src/include/libpq/libpq.h,  /*   * prototypes for functions in be-secure.c   */ extern PGDLLIMPORT char *ssl_library; extern PGDLLIMPORT char *ssl_cert_file; ... However, 'ssl_library', 'ssl_cert_file' and

Re: tablecmds.c/MergeAttributes() cleanup

On 30.04.24 21:48, Robert Haas wrote: I took a look at this patch. Currently this case crashes: CREATE TABLE cmdata(f1 text COMPRESSION pglz); CREATE TABLE cmdata3(f1 text); CREATE TABLE cminh() INHERITS (cmdata, cmdata3); The patch makes this succeed, but I was initially unclear why it didn't

Re: Support LIKE with nondeterministic collations

On 03.05.24 02:11, Robert Haas wrote: On Thu, May 2, 2024 at 9:38 AM Peter Eisentraut wrote: On 30.04.24 14:39, Daniel Verite wrote: postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct; ?column? -- f (1 row) The first two results look fine, but the next one

Re: Rename libpq trace internal functions

On 24.04.24 12:34, Yugo NAGATA wrote: On Wed, 24 Apr 2024 09:39:02 +0200 Peter Eisentraut wrote: libpq's pqTraceOutputMessage() used to look like this: case 'Z': /* Ready For Query */ pqTraceOutputZ(conn->Pfdebug, message, ); break; Commit f4b54e1e

Re: Support LIKE with nondeterministic collations

On 30.04.24 14:39, Daniel Verite wrote: postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct; ?column? -- f (1 row) The first two results look fine, but the next one is inconsistent. This is correct, because '_' means "any single character". This is independent of

Re: small documentation fixes related to collations/ICU

On 29.04.24 09:18, Kashif Zeeshan wrote: Looks good. On Mon, Apr 29, 2024 at 12:05 PM Peter Eisentraut <mailto:pe...@eisentraut.org>> wrote: I found two mistakes related to collation and/or ICU support in the documentation that should probably be fixed and backpatc

Re: Tarball builds in the new world order

On 26.04.24 21:24, Tom Lane wrote: Concretely, I'm proposing the attached. Peter didn't like PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not wedded to that if a better name is proposed. Um, "refspec" leads me here ,

Re: Tarball builds in the new world order

On 26.04.24 21:24, Tom Lane wrote: Concretely, I'm proposing the attached. Peter didn't like PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not wedded to that if a better name is proposed. This seems ok to me, but note that we do have an equivalent implementation in meson. If we

Re: Support a wildcard in backtrace_functions

On 27.04.24 00:16, Michael Paquier wrote: On Fri, Apr 26, 2024 at 02:39:16PM -0400, Tom Lane wrote: Well, in that case we have to have some kind of control GUC, and I think the consensus is that the one we have now is under-designed. So I also vote for a full revert and try again in v18.

small documentation fixes related to collations/ICU

I found two mistakes related to collation and/or ICU support in the documentation that should probably be fixed and backpatched. See attached patches.From 44ea0d75f2739b6a3eed9a0233c3dcb2a64b2538 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 29 Apr 2024 08:50:20 +0200 Subject

Support LIKE with nondeterministic collations

tring.From 3f6b584a0f34cabecac69f3cfd663dadfd34f464 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 29 Apr 2024 07:58:20 +0200 Subject: [PATCH v1] Support LIKE with nondeterministic collations This allows for example using LIKE with case-insensitive collations. There was previously n

Re: Use XLOG_CONTROL_FILE macro everywhere?

On 26.04.24 22:51, Tom Lane wrote: Robert Haas writes: On Wed, Apr 24, 2024 at 8:04 PM Michael Paquier wrote: Not sure that I would bother with a second one. But, well, why not if people want to rename it, as long as you keep compatibility. I vote for just standardizing on

Re: Remove unnecessary code rom be_lo_put()

On 24.04.24 15:25, Tom Lane wrote: Peter Eisentraut writes: On 24.04.24 11:59, Yugo NAGATA wrote: I noticed that a permission check is performed in be_lo_put() just after returning inv_open(), but teh permission should be already checked in inv_open(), so I think we can remove this part

Re: Remove unnecessary code rom be_lo_put()

On 25.04.24 01:50, Michael Paquier wrote: On Wed, Apr 24, 2024 at 09:25:09AM -0400, Tom Lane wrote: I agree. Do you want to do the honors? Good catch. The same check happens when the object is opened. Note that you should be able to remove utils/acl.h at the top of be-fsstubs.c as this

Re: AIX support

On 25.04.24 06:20, Tom Lane wrote: Something I've been mulling over is whether to suggest that the proposed "new port" should only target building with gcc. On the one hand, that would (I think) remove a number of annoying issues, and the average end user is unlikely to care which compiler

Re: Is it acceptable making COPY format extendable?

On 25.04.24 06:53, Sutou Kouhei wrote: I haven't got any reply since 2024-03-15: https://www.postgresql.org/message-id/flat/20240315.173754.2049843193122381085.kou%40clear-code.com#07aefc636d8165204ddfba971dc9a490 (I sent some pings.) So I called this status as "stalled". I'm not familiar with

Re: Experiments with Postgres and SSL

On 01.03.24 22:49, Jacob Champion wrote: If we're interested in ALPN negotiation in the future, we may also want to look at GREASE [1] to keep those options open in the presence of third-party implementations. Unfortunately OpenSSL doesn't do this automatically yet. If we don't have a reason

Re: Experiments with Postgres and SSL

On 08.04.24 10:38, Heikki Linnakangas wrote: On 08/04/2024 04:25, Heikki Linnakangas wrote: One important open item now is that we need to register a proper ALPN protocol ID with IANA. I sent a request for that:

Re: Tarball builds in the new world order

On 24.04.24 00:05, Tom Lane wrote: It makes tarballs all right, but whatever commit ID you specify is semi-ignored, and you get a tarball corresponding to HEAD of master. (The PDFs come from the right version, though!) The reason for that is that the mk-one-release script does this (shorn of

Re: Remove unnecessary code rom be_lo_put()

On 24.04.24 11:59, Yugo NAGATA wrote: I noticed that a permission check is performed in be_lo_put() just after returning inv_open(), but teh permission should be already checked in inv_open(), so I think we can remove this part of codes. I attached a patch for this fix. Yes, I think you are

Re: doc: create table improvements

> + The reliability characteristics of a table are governed by its > + persistence mode. The default mode is described > + here > + There are two alternative modes that can be specified during > + table creation: > + temporary and > + unlogged. Not sure reliability is the best

Re: Why does pgindent's README say to download typedefs.list from the buildfarm?

On 22.04.24 22:28, Tom Lane wrote: Nathan Bossart writes: On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote: I think the actual plan now is that we'll sync the in-tree copy with the buildfarm's results (and then do a tree-wide pgindent) every so often, probably shortly before beta

  1   2   3   4   5   6   7   8   9   10   >