Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM

On Mon, Apr 29, 2024 at 11:36 AM Bharath Rupireddy wrote: > > Please see the attached v20 patch set. It looks like with the use of the new multi insert table access method (TAM) for COPY (v20-0005), pgbench regressed about 35% [1]. The reason is that the memory-based flushing decision the new TAM

Re: cataloguing NOT NULL constraints

On 2024-May-14, Bruce Momjian wrote: > Turns out these commits generated a single release note item, which I > have now removed with the attached committed patch. Hmm, but the commits about not-null constraints for domains were not reverted, only the ones for constraints on relations. I think th

Re: Log details for stats dropped more than once

Hi, On Wed, May 15, 2024 at 02:47:29PM +0900, Michael Paquier wrote: > On Tue, May 14, 2024 at 10:07:14AM +, Bertrand Drouvot wrote: > > While resuming the work on refilenode stats (mentioned in [1] but did not > > share > > the patch yet), I realized that my current POC patch is buggy enough

Re: Avoid orphaned objects dependencies, take 3

Hi, On Wed, May 15, 2024 at 10:14:09AM +0900, Michael Paquier wrote: > On Thu, May 09, 2024 at 12:20:51PM +, Bertrand Drouvot wrote: > > Oh I see, your test updates an existing dependency. v4 took care about > > brand new > > dependencies creation (recordMultipleDependencies()) but forgot to

Re: Avoid orphaned objects dependencies, take 3

Hi, On Tue, May 14, 2024 at 03:00:00PM +0300, Alexander Lakhin wrote: > Hi Bertrand, > > 09.05.2024 15:20, Bertrand Drouvot wrote: > > Oh I see, your test updates an existing dependency. v4 took care about > > brand new > > dependencies creation (recordMultipleDependencies()) but forgot to take

Re: First draft of PG 17 release notes

On 2024-May-14, Bruce Momjian wrote: > On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote: > > I think that we need to more clearly point out the implications of the > > feature added by Sawada-san (and reviewed by John) in 667e65aac35497. > > Vacuum no longer uses a fixed amount of

Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM

Sorry to interject, but -- On 2024-May-15, Bharath Rupireddy wrote: > It looks like with the use of the new multi insert table access method > (TAM) for COPY (v20-0005), pgbench regressed about 35% [1]. Where does this acronym "TAM" comes from for "table access method"? I find it thoroughly hor

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: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM

On Wed, May 15, 2024 at 2:44 PM Alvaro Herrera wrote: > > > It looks like with the use of the new multi insert table access method > > (TAM) for COPY (v20-0005), pgbench regressed about 35% [1]. > > Where does this acronym "TAM" comes from for "table access method"? Thanks for pointing it out. I

Re: Avoid orphaned objects dependencies, take 3

Hi, On Wed, May 15, 2024 at 08:31:43AM +, Bertrand Drouvot wrote: > Hi, > > On Wed, May 15, 2024 at 10:14:09AM +0900, Michael Paquier wrote: > > +++ > > b/src/test/modules/test_dependencies_locks/specs/test_dependencies_locks.spec > > > > > > This introduces a module with only one single

Re: First draft of PG 17 release notes

On Wed, 15 May 2024 at 20:38, Alvaro Herrera wrote: > > On 2024-May-14, Bruce Momjian wrote: > > I don't think users really care about these details, just that it is > > faster so they will not be surprised if there is a change. I was > > purposely vague to group multiple commits into the single

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: Fixup a few 2023 copyright years

On Wed, 15 May 2024 at 17:32, Michael Paquier wrote: > While running src/tools/copyright.pl, I have noticed that that a > newline was missing at the end of index_including.sql, as an effect of > the test added by you in a63224be49b8. I've cleaned up that while on > it, as it was getting added aut

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

Hi, On Sun, 12 May 2024 at 14:53, Peter Eisentraut wrote: > > 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

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 1_0

in parentesis is not usual on DOCs

This page has 3 items that are between parentheses, there is an explanation why they are used this way ? https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-TABLE Each syntax element is described below in more detail. *context_item*, *path_expression* [ AS *json_path_name

Re: Converting README documentation to Markdown

> On 13 May 2024, at 09:20, Peter Eisentraut wrote: > I started looking through this and immediately found a bunch of tiny > problems. (This is probably in part because the READMEs under > src/backend/access/ are some of the more complicated ones, but then they are > also the ones that might

Re: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled

On Wed, May 15, 2024 at 9:26 AM Michael Paquier wrote: > > On Tue, May 14, 2024 at 10:22:29AM +, Ilyasov Ian wrote: > > Hello, hackers! > > > > Recently I've been building postgres with different cflags and cppflags. > > And suddenly on REL_15_STABLE, REL_16_STABLE and master > > I faced a fai

Re: in parentesis is not usual on DOCs

> On 15 May 2024, at 14:04, Marcos Pegoraro wrote: > Why (context_item), (path_expression) and (json_path_name) are inside a > parentheses ? This is not usual when explaining any other feature. Agreed, that's inconsisent with how for example json_table_column is documented in the next list ite

Re: cataloguing NOT NULL constraints

On 15.05.24 09:50, Alvaro Herrera wrote: On 2024-May-14, Bruce Momjian wrote: Turns out these commits generated a single release note item, which I have now removed with the attached committed patch. Hmm, but the commits about not-null constraints for domains were not reverted, only the ones

Re: First draft of PG 17 release notes

On Wed, May 15, 2024 at 4:38 AM Alvaro Herrera wrote: > > On 2024-May-14, Bruce Momjian wrote: > > > On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote: > > > > I think that we need to more clearly point out the implications of the > > > feature added by Sawada-san (and reviewed by J

Re: First draft of PG 17 release notes

On Wed, May 15, 2024 at 7:36 AM Bruce Momjian wrote: > > On Wed, May 15, 2024 at 02:03:32PM +1200, David Rowley wrote: > > On Wed, 15 May 2024 at 13:00, Bruce Momjian wrote: > > > > > > On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote: > > > > "Reduce system calls by automatically

Re: query_id, pg_stat_activity, extended query protocol

On 15/5/2024 12:09, Michael Paquier wrote: On Wed, May 15, 2024 at 03:24:05AM +, Imseih (AWS), Sami wrote: I think we should generally report it when the backend executes a job related to the query with that queryId. This means it would reset the queryId at the end of the query execution.

Re: Direct SSL connection with ALPN and HBA rules

On 14/05/2024 01:29, Jacob Champion wrote: Definitely not a major problem, but I think select_next_encryption_method() has gone stale, since it originally provided generality and lines of fallback that no longer exist. In other words, I think the following code is now misleading: if (conn->sslm

RE: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled

Dear Amit, Ian, > I guess it could be more work if we want to enhance the test for > ERRORs other than the primary key violation. One simple fix is to > update the log_offset to the location of the LOG after successful > replication of un-conflicted data. For example, the Log location after > we e

Re: Postgres and --config-file option

On Wed, May 15, 2024 at 2:49 AM Peter Eisentraut wrote: > 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 --co

Re: libpq compression (part 3)

On Tue, May 14, 2024 at 5:21 PM Jacob Burroughs wrote: > The reason for both the semicolons and for not doing this is related > to using the same specification structure as here: > https://www.postgresql.org/docs/current/app-pgbasebackup.html > (specifically the --compress argument). I agree with

RE: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled

Dear Hayato, > I made a patch for confirmation purpose. This worked well on my environment. > Ian, how about you? I checked this patch on my environment. It also works well. I like this change, but as I see it makes a different approach from Michael's advice. Honesly, I do not know what would be

Re: BitmapHeapScan streaming read user and prelim refactoring

Procedural comment: It's better to get this patch committed with an imperfect test case than to have it miss beta1. ...Robert

Re: Fixup a few 2023 copyright years

David Rowley writes: > On Wed, 15 May 2024 at 17:32, Michael Paquier wrote: >> While running src/tools/copyright.pl, I have noticed that that a >> newline was missing at the end of index_including.sql, as an effect of >> the test added by you in a63224be49b8. I've cleaned up that while on >> it,

Re: Postgres and --config-file option

On Wed, 15 May 2024 at 11:49, Peter Eisentraut wrote: > Yeah, some of this is becoming quite unwieldy, if we document and > mention each spelling variant of each option everywhere. > > Maybe if the original problem is that the option --config-file is not > explicitly in the --help output, let's ad

Re: Things I don't like about \du's "Attributes" column

On 14.05.2024 19:03, Robert Haas wrote: I think we should go back to the v4 version of this patch, minus the (ignored) stuff. Thank you for looking into this. I can assume that you support the idea of changing pg_roles. It's great. By the way, I have attached a separate thread[1] about pg_role

Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

On Mon, 2024-05-06 at 16:46 +0200, Laurenz Albe wrote: > Attached is a POC patch that implements that (documentation and > regression tests are still missing) to form a basis for a discussion. ... and here is a complete patch with regression tests and documentation. Yours, Laurenz Albe From 201c2

Re: BitmapHeapScan streaming read user and prelim refactoring

On 2024-May-14, Melanie Plageman wrote: > On Tue, May 14, 2024 at 4:05 PM Alvaro Herrera > wrote: > > I do wonder how do we _know_ that the test is testing what it wants to > > test: > We include the explain output (the plan) to ensure it is still > using a bitmap heap scan. The test exercises

Re: [DOC] Add detail regarding resource consumption wrt max_connections

On Fri, Mar 22, 2024 at 1:57 PM Robert Haas wrote: > Rather, I think that it's entirely appropriate to do what Roberto > suggested, which is to say, let users know that they're going to use > some extra resources if they increase the setting, and then let them > figure out what if anything they wa

Re: Simplify documentation related to Windows builds

On Thu, Apr 11, 2024 at 9:27 PM Michael Paquier wrote: > So, yes, you're right that removing completely this list may be too > aggressive for the end-user. As far as I can see, there are a few > things that stand out: > - Diff is not mentioned in the list of dependencies on the meson page, > and

Re: AIX support

Hi Team, we have any updated from the XLC team, the issue specific to the alignment is fixed and XLC had released it as part of 16.1.0.18. The PTF is available at the below location, You can also find a link here: https://www.ibm.com/support/pages/fix-list-xl-cc-aix. >>/opt/IBM/xlC/16.1.0/bin/x

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: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

On Thu, Apr 4, 2024 at 12:41 AM Erik Wienhold wrote: > Thanks, fixed in v4. Looks like American English prefers that comma and > it's also more common in our docs. Reviewing this patch: - Creates a typed table, which takes its - structure from the specified composite type (name option

Re: Adding the extension name to EData / log_line_prefix

Peter Eisentraut writes: > 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_MODUL

Re: AIX support

On Wed, May 15, 2024 at 03:33:25PM +, Sriram RK wrote: > Hi Team, we have any updated from the XLC team, the issue specific to the > alignment is fixed > and XLC had released it as part of 16.1.0.18. The PTF is available at the > below location, > > You can also find a link here: > https://w

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

On Tue, Apr 23, 2024 at 4:05 PM Nathan Bossart wrote: > Here is a first attempt. I'm not tremendously happy with it, but it at > least gets something on the page to build on. I was originally going to > copy/paste the relevant steps into the description of the incremental > process, but that see

Re: AIX support

> > Also would like to know some info related to the request raised for > > buildfarm access, to register the > > node in OSU lab. Where can I get the status of the request? Whom can I > > contact to get the request > > approved? So that we can add the node to the buildfarm. > I assume you fille

Re: libpq compression (part 3)

On Wed, May 15, 2024 at 8:38 AM Robert Haas wrote: > > I agree with that goal, but I'm somewhat confused by how your proposal > achieves it. You had > libpq_compression=lzma:client_to_server=off;gzip:server_to_client=off, > so how do we parse that? Is that two completely separate > specifications,

Re: libpq compression (part 3)

On Wed, May 15, 2024 at 12:24 PM Jacob Burroughs wrote: > > But now I'm wondering whether these options should really be symmetric > > on the client and server sides? Isn't it for the server just to > > specify a list of acceptable algorithms, and the client to set the > > compression options? If

Re: GenBKI emits useless open;close for catalogs without rows

On Tue, Apr 9, 2024 at 12:03 AM Michael Paquier wrote: > Hmm, is that productive? This patch has been waiting on author since > the 1st of February, and it was already moved from the CF 2024-01 to > 2024-03. It would make more sense to me to mark it as RwF, then > resubmit if there is still inte

Re: libpq compression (part 3)

On Wed, May 15, 2024 at 11:31 AM Robert Haas wrote: > From my point of view, it's the client who knows what it wants to do > with the connection. If the client plans to read a lot of data, it > might want the server to compress that data, especially if it knows > that it's on a slow link. If the c

Re: Adding the extension name to EData / log_line_prefix

On 05/15/24 11:50, Tom Lane wrote: > Hmm, cute idea, but it'd only help for extensions that are > NLS-enabled. Which I bet is a tiny fraction of the population. > So far as I can find, we don't even document how to set up > TEXTDOMAIN for an extension --- you have to cargo-cult the But I'd bet, w

Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block

On Tue, Apr 16, 2024 at 3:16 AM Quan Zongliang wrote: > According to the discussion with Jian He. Use the guc hook to check if > the xid needs to be output. If needed, the statement log can be delayed > to be output. I appreciate the work that both of you have put into this, but I think we should

Re: Adding the extension name to EData / log_line_prefix

Hi, On 2024-05-15 12:54:45 -0400, Chapman Flack wrote: > On 05/15/24 11:50, Tom Lane wrote: > > Hmm, cute idea, but it'd only help for extensions that are > > NLS-enabled. Which I bet is a tiny fraction of the population. > > So far as I can find, we don't even document how to set up > > TEXTDOMA

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

On Sun, Feb 25, 2024 at 5:24 PM Tomas Vondra wrote: > I think there's about 0% chance we'd add this to "postgres" binary. Several people have taken this position, so I'm going to mark https://commitfest.postgresql.org/48/4704/ as Rejected. My own opinion is that syntax checking is a useful thing

Re: Adding the extension name to EData / log_line_prefix

Andres Freund writes: > On 2024-05-15 12:54:45 -0400, Chapman Flack wrote: >> But I'd bet, within the fraction of the population that does use it, >> it is already a short string that looks a whole lot like the name >> of the extension. So maybe enhancing the documentation and making it >> easy to

Re: Adding the extension name to EData / log_line_prefix

On 05/15/24 13:45, Tom Lane wrote: > if we tell people to write > >PG_MODULE_MAGIC; >#undef TEXTDOMAIN >#define TEXTDOMAIN PG_TEXTDOMAIN("hstore") > > then that's 100% backwards compatible and they don't need any > version-testing ifdef's. OT for this thread, but related: supposing o

Re: psql JSON output format

On Tue, Jan 23, 2024 at 11:35 AM Christoph Berg wrote: > Ack. The last version of this patch was posted on January 22nd and got a bunch of replies, so I'm marking https://commitfest.postgresql.org/48/4707/ as Returned with Feedback for now. Please feel free to update the status of the patch when

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

st 15. 5. 2024 v 19:43 odesílatel Robert Haas napsal: > > On Sun, Feb 25, 2024 at 5:24 PM Tomas Vondra > wrote: > > I think there's about 0% chance we'd add this to "postgres" binary. > > Several people have taken this position, so I'm going to mark > https://commitfest.postgresql.org/48/4704/ as

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

pá 15. 12. 2023 v 15:50 odesílatel Tom Lane napsal: > > Laurenz Albe writes: > > On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote: > >> Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list > >> of ideas for PostgreSQL > >> (https://riggs.business/blog/f/postgresql-todo-2023

Re: Use streaming read API in ANALYZE

Hi, On Mon, 29 Apr 2024 at 18:41, Nazir Bilal Yavuz wrote: > > Hi, > > On Mon, 8 Apr 2024 at 04:21, Thomas Munro wrote: > > > > Pushed. Thanks Bilal and reviewers! > > I wanted to discuss what will happen to this patch now that > 27bc1772fc8 is reverted. I am continuing this thread but I can cr

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

On Tue, May 14, 2024 at 11:15 PM Peter Eisentraut wrote: > > On 15.05.24 02:00, Michael Paquier wrote: > > Is that a recent regression? I have some blurry memories from > > working on these areas that changing src/common/ reflected on the > > compiled pieces effectively at some point. > > One ins

Re: Direct SSL connection with ALPN and HBA rules

On Wed, May 15, 2024 at 6:33 AM Heikki Linnakangas wrote: > Ok, yeah, I can see that now. Here's a new version to address that. I > merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method, > ENC_SSL. The places that need to distinguish between them now check > conn-sslnegotiation.

Re: Support a wildcard in backtrace_functions

Hi, This patch is currently parked in the July CommitFest: https://commitfest.postgresql.org/48/4735/ That's fine, except that I think that what the previous discussion revealed is that we don't have consensus on how backtrace behavior ought to be controlled: backtrace_on_internal_error was one

Re: query_id, pg_stat_activity, extended query protocol

> Okay, that's what I precisely wanted to understand: queryId doesn't have > semantics to show the job that consumes resources right now—it is mostly > about convenience to know that the backend processes nothing except > (probably) this query. It may be a good idea to expose in pg_stat_activity o

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

=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes: > I'm not sure everyone in this thread understands the reason for this > patch, which is clearly my fault, since I have failed to explain. Main > idea is to make a tool to validate query can be parsed, that's all. > Similar to running "EXPLAIN query", but n

Fix PGresult leak in pg_dump during binary upgrade

While looking at pg_dump performance today I noticed that pg_dump fails to clear query results in binary_upgrade_set_pg_class_oids during binary upgrade mode. 9a974cbcba00 moved the query to the outer block, but left the PQclear and query buffer destruction in the is_index conditional, making it n

Re: add function argument names to regex* functions.

On Thu, Apr 4, 2024 at 9:55 AM jian he wrote: > in the regexp_replace explanation section. > changing "N" to lower-case would be misleading for regexp_replace? > so I choose "count". I don't see why that would be confusing for regexp_replace specifically, but I think N => count is a reasonable ch

Re: Fix PGresult leak in pg_dump during binary upgrade

Daniel Gustafsson writes: > While looking at pg_dump performance today I noticed that pg_dump fails to > clear query results in binary_upgrade_set_pg_class_oids during binary upgrade > mode. 9a974cbcba00 moved the query to the outer block, but left the PQclear > and query buffer destruction in th

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

Tom Lane: The thing that was bothering me most about this is that I don't understand why that's a useful check. If I meant to type UPDATE mytab SET mycol = 42; and instead I type UPDATEE mytab SET mycol = 42; your proposed feature would catch that; great. But if I type

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 2:46 PM Robert Haas wrote: > Examples in the regression tests aren't meant as tests, not examples > for users to copy. If we want examples, those belong in the > documentation. However, I see that regexp_replace already has some > examples at > https://www.postgresql.org/d

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

st 15. 5. 2024 v 20:39 odesílatel Tom Lane napsal: > > =?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes: > > I'm not sure everyone in this thread understands the reason for this > > patch, which is clearly my fault, since I have failed to explain. Main > > idea is to make a tool to validate query can be p

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

walt...@technowledgy.de writes: > Tom Lane: >> BTW, if you do feel that a pure grammar check is worthwhile, you >> should look at the ecpg preprocessor, which does more or less that >> with the SQL portions of its input. > Would working with ecpg allow to get back a parse tree of the query to > d

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 11:46 AM Robert Haas wrote: > On Thu, Apr 4, 2024 at 9:55 AM jian he > wrote: > > in the regexp_replace explanation section. > > changing "N" to lower-case would be misleading for regexp_replace? > > so I choose "count". > > I don't see why that would be confusing for reg

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

On Wed, May 15, 2024 at 2:39 PM Tom Lane wrote: > The thing that was bothering me most about this is that I don't > understand why that's a useful check. If I meant to type > > UPDATE mytab SET mycol = 42; > > and instead I type > > UPDATEE mytab SET mycol = 42; > > your proposed

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

On Wed, May 15, 2024 at 2:12 PM Josef Šimánek wrote: > I'm totally OK to mark this as rejected and indeed 45 lines were just > minimal patch to create PoC (I have coded this during last PGConf.eu > lunch break) and mainly to start discussion. Thanks for understanding. > I'm not sure everyone in

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 3:01 PM David G. Johnston wrote: > I think this confusion goes to show that replacing N with count doesn't work. > > "replace_at" comes to mind as a better name. I do not agree with that at all. It shows that a literal search-and-replace changing N to count does not work,

Re: add function argument names to regex* functions.

Robert Haas writes: > On Thu, Apr 4, 2024 at 9:55 AM jian he wrote: >> changing "N" to lower-case would be misleading for regexp_replace? >> so I choose "count". > I don't see why that would be confusing for regexp_replace > specifically, but I think N => count is a reasonable change to make. >

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

Tom Lane: This is really what is missing for the ecosystem. A libpqparser for tools to use: Formatters, linters, query rewriters, simple syntax checkers... they are all missing access to postgres' own parser. To get to that, you'd need some kind of agreement on what the syntax tree is. I doubt

Re: Incorrect Assert in BufFileSize()?

On Tue, May 14, 2024 at 6:58 AM David Rowley wrote: > On Fri, 3 May 2024 at 16:03, David Rowley wrote: > > I'm trying to figure out why BufFileSize() Asserts that file->fileset > > isn't NULL, per 1a990b207. > > I was hoping to get some feedback here. Notice that comments above BufFileSize() say

Re: add function argument names to regex* functions.

On 05/15/24 15:07, Robert Haas wrote: > is. I believe that if I were reading the documentation, count would be > clearer to me than N, N would probably still be clear enough, and > replace_at wouldn't be clear at all. I'd expect replace_at to be a > character position or something, not an occurrenc

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 12:07 PM Robert Haas wrote: > On Wed, May 15, 2024 at 3:01 PM David G. Johnston > wrote: > > I think this confusion goes to show that replacing N with count doesn't > work. > > > > "replace_at" comes to mind as a better name. > > I do not agree with that at all. It shows

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

Robert Haas writes: > On Wed, May 15, 2024 at 2:39 PM Tom Lane wrote: >> The thing that was bothering me most about this is that I don't >> understand why that's a useful check. ... > But I don't understand the idea that the concept doesn't make sense. Sorry: "make sense" was a poorly chosen ph

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

On Wed, May 15, 2024 at 12:06:03PM -0400, Robert Haas wrote: > What jumps out at me when I read this patch is that it says that an > incremental run should do steps 1-3 of a complete run, and then > immediately backtracks and says not to do step 2, which seems a little > strange. > > I played arou

Re: date_trunc function in interval version

On Mon, Mar 4, 2024 at 5:03 AM Przemysław Sztoch wrote: > Apparently the functionality is identical to date_bin. > When I saw date_bin in the documentation, I thought it solved all my problems. > Unfortunately, DST problems have many corner cases. > I tried to change date_bin several times, but un

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 3:23 PM Chapman Flack wrote: > What would be wrong with that, for consistency's sake? It was proposed and rejected upthread, but that's not to say that I necessarily endorse the reasons given. -- Robert Haas EDB: http://www.enterprisedb.com

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

On Wed, May 15, 2024 at 12:18 PM wrote: > Tom Lane: > >> This is really what is missing for the ecosystem. A libpqparser for > >> tools to use: Formatters, linters, query rewriters, simple syntax > >> checkers... they are all missing access to postgres' own parser. > > > > To get to that, you'd n

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

st 15. 5. 2024 v 21:28 odesílatel Tom Lane napsal: > > Robert Haas writes: > > On Wed, May 15, 2024 at 2:39 PM Tom Lane wrote: > >> The thing that was bothering me most about this is that I don't > >> understand why that's a useful check. ... > > > But I don't understand the idea that the concep

Re: An improved README experience for PostgreSQL

On Wed, May 15, 2024 at 07:23:19AM +0200, Peter Eisentraut wrote: > I think for CONTRIBUTING.md, a better link would be > . WFM -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From 74de0e89bea2802bf699397837ebf77252a0e06b Mon Sep 17 00:00:00

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

st 15. 5. 2024 v 21:33 odesílatel David G. Johnston napsal: > > On Wed, May 15, 2024 at 12:18 PM wrote: >> >> Tom Lane: >> >> This is really what is missing for the ecosystem. A libpqparser for >> >> tools to use: Formatters, linters, query rewriters, simple syntax >> >> checkers... they are all

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

On Wed, May 15, 2024 at 12:35 PM Josef Šimánek wrote: > st 15. 5. 2024 v 21:33 odesílatel David G. Johnston > napsal: > > > Now, in my ideal world something like this could be made as an extension > so that it can work on older versions and not have to be maintained by > core. And likely grow m

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

"David G. Johnston" writes: > Now, in my ideal world something like this could be made as an extension so > that it can work on older versions and not have to be maintained by core. > And likely grow more features over time. Is there anything fundamental > about this that prevents it being implem

More links on release-17.html

While seeing changes and new features of https://www.postgresql.org/docs/devel/release-17.html I see that there are too little links to other DOC pages, which would be useful. There are links to "logical-replication", "sql-merge", "plpgsql", "libpq" and "pgstatstatements" But no one link is avail

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 3:25 PM David G. Johnston wrote: > The function replaces matches, not random characters. And if you are reading > the documentation I find it implausible that the wording I suggested would > cause one to think in terms of characters instead of matches. I mean I just tol

Re: [DOC] Add detail regarding resource consumption wrt max_connections

On Wed, May 15, 2024 at 11:14 AM Robert Haas wrote: > > On Fri, Mar 22, 2024 at 1:57 PM Robert Haas wrote: > > Rather, I think that it's entirely appropriate to do what Roberto > > suggested, which is to say, let users know that they're going to use > > some extra resources if they increase the s

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

On Wed, May 15, 2024 at 3:28 PM Tom Lane wrote: > Sorry: "make sense" was a poorly chosen phrase there. What I was > doubting, and continue to doubt, is that 100% checking of what > you can check without catalog access and 0% checking of the rest > is a behavior that end users will find especiall

Re: [DOC] Add detail regarding resource consumption wrt max_connections

On Wed, May 15, 2024 at 4:00 PM Robert Treat wrote: > I think the only unresolved question in my mind was if we should add a > similar note to the original patch to max_prepared_xacts as well; do > you intend to do that? I didn't intend to do that. I don't think it would be incorrect to do so, bu

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

On Wed, May 15, 2024 at 3:30 PM Nathan Bossart wrote: > On Wed, May 15, 2024 at 12:06:03PM -0400, Robert Haas wrote: > > What jumps out at me when I read this patch is that it says that an > > incremental run should do steps 1-3 of a complete run, and then > > immediately backtracks and says not t

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 12:52 PM Robert Haas wrote: > On Wed, May 15, 2024 at 3:25 PM David G. Johnston > wrote: > > The function replaces matches, not random characters. And if you are > reading the documentation I find it implausible that the wording I > suggested would cause one to think in

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 12:07 PM Robert Haas wrote: > On Wed, May 15, 2024 at 3:01 PM David G. Johnston > wrote: > > I think this confusion goes to show that replacing N with count doesn't > work. > > > > "replace_at" comes to mind as a better name. > I'd expect replace_at to be a > character po

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 4:13 PM David G. Johnston wrote: > > You just broke my brain when you say that you read: > > By default, only the first match of the pattern is replaced. If replace_at > is specified and greater than zero, then the first "replace_at - 1" matches > are skipped before maki

Re: More performance improvements for pg_dump in binary upgrade mode

On Wed, May 15, 2024 at 10:15:13PM +0200, Daniel Gustafsson wrote: > With the typarray caching from the patch attached here added *and* Nathan's > patch from [0] added: > > $ time ./bin/pg_dump --schema-only --quote-all-identifiers --binary-upgrade \ > --format=custom --file a postgres > /dev/nu

Re: [DOC] Add detail regarding resource consumption wrt max_connections

On Wed, May 15, 2024 at 4:05 PM Robert Haas wrote: > > On Wed, May 15, 2024 at 4:00 PM Robert Treat wrote: > > I think the only unresolved question in my mind was if we should add a > > similar note to the original patch to max_prepared_xacts as well; do > > you intend to do that? > > I didn't in

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

Robert Haas writes: > On Wed, May 15, 2024 at 3:30 PM Nathan Bossart > wrote: >> This is much cleaner, thanks. The only thing that stands out to me is that >> the "once per release cycle" section should probably say to do an indent >> run after downloading the typedef file. > How's this? This

  1   2   >