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&#x

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: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-commu

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 pg_comb

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 forbids

doc: some fixes for environment sections in ref pages

.From 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

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

d tests in some way. From 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 r

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 configuratio

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 in

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 and

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 e

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 a

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

ed 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 idea

consider -Wmissing-variable-declarations

vious 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

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 th

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 t

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 du

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. +

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 alo

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 pro

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

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.&#x

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 not

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 seem

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 ind

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 json_lex_string(),

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 t

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 fi

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, &logCursor);

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 , whic

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. Okay,

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

this by matching by character, but for nondeterministic collations we have to go by substring.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 T

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 XLOG_CONTROL_FI

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 of

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 woul

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 their

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 not

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: https://mailarchive.ietf.org/arch/msg/tls-reg-review/9LWPzQfOpbc8dTT7vc9ahNeNaiw/

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 no

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 rig

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 word

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 every

Re: Q: Escapes in jsonpath Idents

On 18.03.24 01:09, Erik Wienhold wrote: The error message 'syntax error at or near "$oo" of jsonpath input' for the second case ($.f$oo), however, looks as if the scanner identifies '$oo' as a variable instead of contiuing the scan of identifier (f$oo) for the member accessor. Looks like a bug t

Re: Q: Escapes in jsonpath Idents

On 17.03.24 20:12, Erik Wienhold wrote: Mentioning JSON and \v in the same sentence is wrong: JavaScript allows that escape in strings but JSON doesn't. I think the easiest is to just replace "JSON" with "JavaScript" in that sentence to make it right. The paragraph also already says "embedded s

Re: Use XLOG_CONTROL_FILE macro everywhere?

On 19.04.24 05:50, Anton A. Melnikov wrote: There is a macro XLOG_CONTROL_FILE for control file name defined in access/xlog_internal.h And there are some places in code where this macro is used like here https://github.com/postgres/postgres/blob/84db9a0eb10dd1dbee6db509c0e427fa237177dc/src/bin/pg

Re: Is it acceptable making COPY format extendable?

On 23.04.24 07:14, Sutou Kouhei wrote: Hi, I'm proposing a patch that making COPY format extendable: https://www.postgresql.org/message-id/20231204.153548.2126325458835528809.kou%40clear-code.com https://commitfest.postgresql.org/48/4681/ It's based on the discussion at: https://www.postgresql.

Rename libpq trace internal functions

aceOutput_Describe() and pqTraceOutput_DataRow().From 00a9abce09ec22ff9eb617123bd4bda5701118a2 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Wed, 24 Apr 2024 09:27:46 +0200 Subject: [PATCH] Rename libpq trace internal functions libpq's pqTraceOutputMessage() used to look like th

Re: ecpg_config.h symbol missing with meson

On 17.04.24 18:15, Tom Lane wrote: Peter Eisentraut writes: I checked the generated ecpg_config.h with make and meson, and the meson one is missing #define HAVE_LONG_LONG_INT 1 This is obviously quite uninteresting, since that is required by C99. But it would be more satisfactory if we

Re: Support a wildcard in backtrace_functions

On 19.04.24 21:24, Tom Lane wrote: But on the other hand, in my personal experience, backtrace_on_internal_error would be the right thing in a really large number of cases. That's why I thought we could get away with doing it automatically. Sure, more control would be better. But if we just har

Re: AIX support

On 19.04.24 13:04, Sriram RK wrote: For any complier/hardware related issue we should able to provide support. We are in the process of identifying the AIX systems that can be added to the CI/buildfarm environment. I think we should manage expectations here, if there is any hope of getting A

Re: Support a wildcard in backtrace_functions

On 18.04.24 11:54, Jelte Fennema-Nio wrote: On Thu, 18 Apr 2024 at 10:50, Peter Eisentraut wrote: Why exactly is this an open item? Is there anything wrong with the existing feature? The name of the GUC backtrace_on_internal_error is so specific that it's impossible to extend our back

Re: Idea Feedback: psql \h misses -> Offers Links?

On 18.04.24 23:29, Kirk Wolak wrote: On Thu, Apr 18, 2024 at 2:37 PM Peter Eisentraut <mailto:pe...@eisentraut.org>> wrote: On 17.04.24 19:47, Kirk Wolak wrote: > *Example:* > \h current_setting > No help available for "current_setting". >

Re: Cannot find a working 64-bit integer type on Illumos

On 18.04.24 02:31, Thomas Munro wrote: For limits, why do we have this: - * stdint.h limits aren't guaranteed to have compatible types with our fixed - * width types. So just define our own. ? I mean, how could they not have compatible types? The commit for this was 62e2a8dc2c7 and the threa

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

On 19.04.24 07:37, Michael Paquier wrote: On Thu, Apr 18, 2024 at 12:53:43PM +0200, Peter Eisentraut wrote: If everything is addressed, I agree that 0001, 0003, and 0004 can go into PG17, the rest later. About the PG17 bits, would you agree about a backpatch? Or perhaps you disagree? I

Re: [18] clarify the difference between pg_wchar, wchar_t, and Unicode code points

On 16.04.24 01:40, Jeff Davis wrote: I'm not sure I understand all of the history behind pg_wchar, but it seems to be some blend of: (a) Postgres's own internal representation of a decoded character (b) libc's wchar_t (c) Unicode code point For example, Postgres has its own encoding/de

Re: Idea Feedback: psql \h misses -> Offers Links?

On 17.04.24 19:47, Kirk Wolak wrote: *Example:* \h current_setting No help available for "current_setting". Try \h with no arguments to see available help. https://www.postgresql.org/search/?u=%2Fdocs%2F16%2F&q=current_setting

Re: plenty code is confused about function level static

On 18.04.24 19:11, Andres Freund wrote: Thoughts about when to apply these? Arguably they're fixing mildly broken code, making it appropriate to fix in 17, but it's also something that we could end up fixing for a while... Yeah, let's keep these for later. They are not regressions, and there

Re: Transparent column encryption

On 10.04.24 16:14, Jelte Fennema-Nio wrote: (The CEK can't be rotated easily, since that would require reading out all the data from a table/column and reencrypting it. We could/should add some custom tooling for that, but it wouldn't be a routine operation.) This seems like something that req

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

On 16.04.24 10:17, Daniel Gustafsson wrote: I forgot (and didn't check) that we backpatched 01e6f1a842f4, with that in mind I agree that we should backpatch 0003 as well to put LibreSSL on par as much as we can. 0004 is a fix for the LibreSSL support, not adding anything new, so pushing that to

Re: Combine headerscheck and cpluspluscheck scripts

On 16.04.24 17:17, Anton Voloshin wrote: On 10/03/2024 12:03, Peter Eisentraut wrote: Committed, thanks. This commit (7b8e2ae2f) have turned cpluspluscheck script into a --cplusplus option for headerscheck.  I propose to update the src/tools/pginclude/README correspondingly, please see the

Re: plenty code is confused about function level static

On 18.04.24 10:43, Andrey M. Borodin wrote: On 18 Apr 2024, at 02:39, Andres Freund wrote: There are lots of places that could benefit from adding 'static const'. +1 for helping compiler. GCC has a -Wsuggest-attribute=const, we can count these warnings and threat increase as an error :) Th

Re: Support a wildcard in backtrace_functions

On 18.04.24 09:02, Michael Paquier wrote: On Fri, Apr 12, 2024 at 09:36:36AM +0900, Michael Paquier wrote: log_backtrace speaks a bit more to me as a name for this stuff because it logs a backtrace. Now, there is consistency on HEAD as well because these GUCs are all prefixed with "backtrace_".

Re: Cannot find a working 64-bit integer type on Illumos

On 18.04.24 02:31, Thomas Munro wrote: On Sat, Mar 23, 2024 at 3:23 PM Tom Lane wrote: Thomas Munro writes: . o O ( int64_t, PRIdi64, etc were standardised a quarter of a century ago ) Yeah. Now that we require C99 it's probably reasonable to assume that those things exist. I wouldn't be

Re: plenty code is confused about function level static

On 17.04.24 23:39, Andres Freund wrote: Is there some reason we went for this pattern in a fair number of places? I assume it's mostly copy-pasta, but... Right. I don't think it is commonly understood that adding const qualifiers can help compiler optimization, and it's difficult to systemat

ecpg_config.h symbol missing with meson

I checked the generated ecpg_config.h with make and meson, and the meson one is missing #define HAVE_LONG_LONG_INT 1 This is obviously quite uninteresting, since that is required by C99. But it would be more satisfactory if we didn't have discrepancies like that. Note that we also kept ENABL

Re: some LLVM function checks missing in meson

On 13.04.24 10:25, Heikki Linnakangas wrote: Something like the below would appear to fix that: diff --git a/meson.build b/meson.build index 43fad5323c0..cdfd31377d1 100644 --- a/meson.build +++ b/meson.build @@ -2301,6 +2301,14 @@ decl_checks += [ ['pwritev', 'sys/uio.h'],    ] +# Check p

Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

On 29.03.24 02:42, David G. Johnston wrote: We do use the term "stand-alone composite" in create type so I'm inclined to use it instead of "composite created with CREATE TYPE"; especially in the error messages; I'm a bit more willing to add the cross-reference to create type in the user docs.

Re: Building with meson on NixOS/nixpkgs

On 29.03.24 19:47, walt...@technowledgy.de wrote: > -uuid = dependency('ossp-uuid', required: true) > +# upstream is called "uuid", but many distros change this to "ossp-uuid" > +uuid = dependency('ossp-uuid', 'uuid', required: true) How would this behave if you have only uuid.pc fr

Re: Speed up clean meson builds by ~25%

On 10.04.24 17:33, Tom Lane wrote: The immediate question then is do we want to take Jelte's patch as a way to ameliorate the pain meanwhile. I'm kind of down on it, because AFAICS what would happen if you break the core grammar is that (most likely) the failure would be reported against ecpg fi

Re: some LLVM function checks missing in meson

On 13.04.24 10:25, Heikki Linnakangas wrote: There's also this in llvmjit.c:     if (llvm_opt3_orc)     { #if defined(HAVE_DECL_LLVMORCREGISTERPERF) && HAVE_DECL_LLVMORCREGISTERPERF     if (jit_profiling_support)     LLVMOrcUnregisterPerf(llvm_opt3_orc); #endif    

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

On 24.10.23 22:13, Alexander Korotkov wrote: On Wed, Sep 28, 2022 at 11:44 AM Aleksander Alekseev wrote: I think, this patch was marked as "Waiting on Author", probably, by mistake. Since recent changes were done without any significant code changes and CF bot how happy again. I'm going to m

Re: Catalog domain not-null constraints

On 09.04.24 10:44, jian he wrote: After studying this a bit more, I think moving forward in this direction is the best way. Attached is a new patch version, mainly with a more elaborate commit message. This patch makes the not-null constraint syntax consistent between CREATE DOMAIN and ALTER DO

Re: PG_TEST_EXTRAs by theme rather than test name (Re: pgsql: Add tests for libpq gssencmode and sslmode options)

On 12.04.24 19:03, Heikki Linnakangas wrote: As we accumulate more PG_TEST_EXTRA options, I think we should categorize the tests by the capabilities they need or the risk associated, rather than by test names. This was recently discussed at [0], without success. [0]: https://www.postgresql.o

some LLVM function checks missing in meson

I have been checking the pg_config.h generated by configure and meson to see if there is anything materially different. I found that HAVE_DECL_LLVMCREATEGDBREGISTRATIONLISTENER and HAVE_DECL_LLVMCREATEPERFJITEVENTLISTENER are missing on the meson side. Something like the below would appear to

Re: ❓ JSON Path Dot Precedence

On 07.04.24 18:13, David E. Wheeler wrote: Hello Hackers, A question about the behavior of the JSON Path parser. The docs[1] have this to say about numbers: Numeric literals in SQL/JSON path expressions follow JavaScript rules, which are different from both SQL and JSON in some minor detai

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On 05.04.24 14:55, Robert Haas wrote: I also wonder how the protocol negotiation for column encryption is actually going to work. What are the actual wire protocol changes that are needed? What does the server need to know from the client, or the client from the server, about what is supported?

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

On 06.04.24 19:47, Daniel Gustafsson wrote: In bumping we want to move to 1.1.1 since that's the first version with the rewritten RNG which is fork-safe by design, something PostgreSQL clearly benefits from. I think it might be better to separate this into two steps: 1. Move to 1.1.0. This is

Re: post-freeze damage control

On 09.04.24 00:58, Michael Paquier wrote: That's more linked to the fact that I was going silent without a laptop for a few weeks before the end of the release cycle, and a way to say to not count on me, while I was trying to keep my room clean to avoid noise for others who would rush patches. I

Re: documentation structure

On 05.04.24 17:11, Robert Haas wrote: 4. Consolidate the "Generic WAL Records" and "Custom WAL Resource Managers" chapters, which cover related topics, into a single one. I didn't see anyone object to this, but David Johnston pointed out that the patch I posted was a few bricks short of a load, b

Re: Catalog domain not-null constraints

On 21.03.24 12:23, Peter Eisentraut wrote: All the examples in the tests append "value" to this, presumably by analogy with CHECK constraints, but it looks as though anything works, and is simply ignored: ALTER DOMAIN d ADD CONSTRAINT nn NOT NULL xxx; -- works That doesn't se

Re: Speed up clean meson builds by ~25%

On 05.04.24 18:19, Jelte Fennema-Nio wrote: On Fri, 5 Apr 2024 at 17:24, Andres Freund wrote: I recommend opening a bug report for clang, best with an already preprocessed input file. We're going to need to do something about this from our side as well, I suspect. The times aren't great with

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

On 05.04.24 23:48, Daniel Gustafsson wrote: The reason to expand the check is to ensure that we have the version we want for both OpenSSL and LibreSSL, and deprecating OpenSSL versions isn't all that commonly done so having to change the version in the check didn't seem that invasive to me. Why

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

On 05.04.24 18:59, Daniel Gustafsson wrote: Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1 fails on Windows in CI which I will investigate next. I'm not a fan of the new PGAC_CHECK_OPENSSL. It creates a second place where the OpenSSL version number has to be updated.

Re: Psql meta-command conninfo+

On 04.04.24 18:15, Maiquel Grassi wrote: Well, I can revert \conninfo to its original state and keep \conninfo+ as it is, perhaps removing the application name, as I believe everything else is important for a DBA/SysAdmin. Do you think we can proceed with the patch this way? I am open to ideas th

Re: Add trim_trailing_whitespace to editorconfig file

On 04.04.24 16:58, Jelte Fennema-Nio wrote: On Thu, 4 Apr 2024 at 15:25, Peter Eisentraut wrote: Everybody has git. Everybody who edits .gitattributes can use git to check what they did. What CLI command do you use to fix/ gitattributes on all existing files? Afaict there's no comma

Re: Psql meta-command conninfo+

The existing \conninfo command gets its values from libpq APIs. You are changing all of this to make a server query, which is a totally different thing. If we wanted to take a change like this, I don't think it should be reusing the \conninfo command. But I don't really see the point of this

<    1   2   3   4   5   6   7   8   9   10   >