Pre-Commitfest Party on StHighload conf

Hi hackers! StHighload conference will be held on June 24-25[0]. I’m planning to do “Pre-Commitfest Party” there. The idea is to help promote patches among potential reviewers. And start working with the very beginning of PG18 development cycle. Good patch review of a valuable feature is a

Re: PostgreSQL 17 Beta 1 release announcement draft

On Thu, May 16, 2024, 06:37 zaidagilist wrote: > Hello, > > I am trying to open the 17 docs but it looks removed. Getting > following message "Page not found" > > https://www.postgresql.org/docs/17/ > > > Regards, > Zaid Shabbir > That link isn't set up yet, but will be (or should be) when the

Re: PostgreSQL 17 Beta 1 release announcement draft

Hello, I am trying to open the 17 docs but it looks removed. Getting following message "Page not found" https://www.postgresql.org/docs/17/ Regards, Zaid Shabbir On Thu, May 16, 2024 at 10:16 AM Bertrand Drouvot wrote: > > Hi, > > On Wed, May 15, 2024 at 09:45:35PM -0400, Jonathan S. Katz

Re: query_id, pg_stat_activity, extended query protocol

On 15.05.2024 10:24, Imseih (AWS), Sami wrote: I discovered the current state of queryId reporting and found that it may be unlogical: Postgres resets queryId right before query execution in simple protocol and doesn't reset it at all in extended protocol and other ways to execute queries. In

Re: PostgreSQL 17 Beta 1 release announcement draft

Hi, On Wed, May 15, 2024 at 09:45:35PM -0400, Jonathan S. Katz wrote: > Hi, > > Attached is a copy of the PostgreSQL 17 Beta 1 release announcement draft. Thanks for working on it! I've one comment: > PostgreSQL 17 also introduces a new view, >

Re: Docs: Always use true|false instead of sometimes on|off for the subscription options

On Thu, 16 May 2024 at 12:29, Peter Smith wrote: > There are lots of subscription options listed on the CREATE > SUBSCRIPTION page [1]. > > Although these boolean options are capable of accepting different > values like "1|0", "on|off", "true|false", here they are all described > only using

Re: PostgreSQL 17 Beta 1 release announcement draft

On Thu, May 16, 2024, 02:45 Jonathan S. Katz wrote: > Hi, > > Attached is a copy of the PostgreSQL 17 Beta 1 release announcement > draft. This contains a user-facing summary of some of the features that > will be available in the Beta, as well as a call to test. I've made an > effort to group

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

Dear Peter, > You wrote "Fixed" for that patch v9-0004 suggestion but I don't think > anything was changed at all. Accidentally missed? Sorry, I missed to do `git add` after the revision. The change was also included in new patch [1]. [1]:

Re: in parentesis is not usual on DOCs

On Wed, May 15, 2024 at 8:34 PM Daniel Gustafsson wrote: > > > 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

Re: PostgreSQL 17 Beta 1 release announcement draft

Hi Jonathan Did the review and did not find any issues. Regards Kashif Zeeshan Bitnine Global On Thu, May 16, 2024 at 6:45 AM Jonathan S. Katz wrote: > Hi, > > Attached is a copy of the PostgreSQL 17 Beta 1 release announcement > draft. This contains a user-facing summary of some of the

Re: First draft of PG 17 release notes

Hi, On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote: > I disagree with this. IMO the impact of the Sawada/Naylor change is > likely to be enormous for people with large tables and large numbers of > tuples to clean up (I know we've had a number of customers in this > situation, I can't

Re: First draft of PG 17 release notes

On Thu, 16 May 2024 at 14:48, Bruce Momjian wrote: > > On Wed, May 15, 2024 at 09:13:14AM -0400, Melanie Plageman wrote: > > Also +1 on the Sawada/Naylor change being on the highlight section of > > the release (as David suggested upthread). > > Agreed, I went with the attached applied patch.

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

On Thu, May 16, 2024 at 3:43 AM Michael Paquier wrote: > > On Wed, May 15, 2024 at 05:58:18PM +0530, Amit Kapila wrote: > > I guess it could be more work if we want to enhance the test for > > ERRORs other than the primary key violation. > > And? You could pass the ERROR string expected as

Re: More links on release-17.html

On Wed, May 15, 2024 at 04:50:47PM -0300, Marcos Pegoraro wrote: > 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",

Re: cataloguing NOT NULL constraints

On Wed, May 15, 2024 at 09:50:36AM +0200, Álvaro 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

Re: First draft of PG 17 release notes

On Thu, May 16, 2024 at 10:39:18AM +0800, jian he wrote: > On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote: > > > > I have committed the first draft of the PG 17 release notes; you can > > see the results here: > > > > https://momjian.us/pgsql_docs/release-17.html > > > > >> Add

Re: First draft of PG 17 release notes

On Wednesday, May 15, 2024, jian he wrote: > On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote: > > > > I have committed the first draft of the PG 17 release notes; you can > > see the results here: > > > > https://momjian.us/pgsql_docs/release-17.html > > > > in section: E.1.2.

Re: First draft of PG 17 release notes

On Wed, May 15, 2024 at 09:13:14AM -0400, Melanie Plageman wrote: > I think this wording and organization makes sense. I hadn't thought of > using "traffic" to describe this, but I like it. > > Also +1 on the Sawada/Naylor change being on the highlight section of > the release (as David suggested

Re: [PoC] Reducing planning time when tables have many partitions

Hello, Thank you for reviewing these patches. On Thu, May 2, 2024 at 11:35 PM jian he wrote: > on v24-0001: > +/* > + * add_eq_member - build a new EquivalenceMember and add it to an EC > + */ > +static EquivalenceMember * > +add_eq_member(EquivalenceClass *ec, Expr *expr, Relids relids, > +

Re: PostgreSQL 17 Beta 1 release announcement draft

Thanks for writing that up. It's always exciting to see this each year. On Thu, 16 May 2024 at 13:45, Jonathan S. Katz wrote: > * Please indicate if you believe there's a notable omission, or if we > should omit any of these callouts I'd say the streaming read stuff added in b5a9b18cd and

Re: First draft of PG 17 release notes

On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote: > > I have committed the first draft of the PG 17 release notes; you can > see the results here: > > https://momjian.us/pgsql_docs/release-17.html > >> Add local I/O block read/write timing statistics columns of >> pg_stat_statement

Re: Requiring LLVM 14+ in PostgreSQL 18

On Wed, May 15, 2024 at 5:20 PM Peter Eisentraut wrote: > Yes, let's get that v3-0001 patch into PG17. Done. Bilal recently created the CI images for Debian Bookworm[1]. You can try them with s/bullseye/bookworm/ in .cirrus.tasks.yml, but it looks like he is still wrestling with a perl

PostgreSQL 17 Beta 1 release announcement draft

Hi, Attached is a copy of the PostgreSQL 17 Beta 1 release announcement draft. This contains a user-facing summary of some of the features that will be available in the Beta, as well as a call to test. I've made an effort to group them logically around the different workflows they affect. A

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

On Wed, May 15, 2024 at 6:35 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > > If in core I would still want to expose this as say a contrib module > binary instead of hacking it into postgres. It would be our first server > program entry there. > > Sorry for self-reply but: Maybe

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

On Wed, May 15, 2024 at 1:00 PM Robert Haas wrote: > 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

Re: Why is citext/regress failing on hamerkop?

On Thu, May 16, 2024 at 10:43 AM Thomas Munro wrote: > Any chance you could test this version please Alexander? Sorry, cancel that. v3 is not good. I assume it fixes the GSSAPI thing and is superficially better, but it doesn't handle code that calls twice in a row and ignores the first result

Re: query_id, pg_stat_activity, extended query protocol

On Wed, May 15, 2024 at 06:36:23PM +, Imseih (AWS), Sami wrote: >> 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 >>

Re: CREATE TABLE/ProcessUtility hook behavior change

On 4/30/24 21:15, jian he wrote: On Tue, Apr 30, 2024 at 4:35 PM David Steele wrote: On 4/30/24 12:57, jian he wrote: On Tue, Apr 30, 2024 at 10:26 AM David Steele wrote: Since bb766cde cannot be readily applied to older commits in master I'm unable to continue bisecting to find the ALTER

Re: explain format json, unit for serialize and memory are different.

On Wed, 15 May 2024 at 13:23, Tom Lane wrote: > > Michael Paquier writes: > > Perhaps Alvaro and Tom would like to chime in, as committers of > > respectively 5de890e3610d and 06286709ee06? > > No objection here. In a green field I might argue for > round-to-nearest instead of round-up, but it

Docs: Always use true|false instead of sometimes on|off for the subscription options

Hi hackers, There are lots of subscription options listed on the CREATE SUBSCRIPTION page [1]. Although these boolean options are capable of accepting different values like "1|0", "on|off", "true|false", here they are all described only using values "true|false". ~ IMO this consistent way of

Re: Postgres and --config-file option

On Wed, May 15, 2024 at 04:47:27PM +0200, Jelte Fennema-Nio wrote: > I definitely think it would be useful to list this --config variant in > more places, imho it's nicer than the -c variant. Especially in the > PGOPTIONS docs it would be useful. People are already using it in the > wild and I

Re: Statistics Import and Export

On Mon, 2024-05-06 at 23:43 -0400, Corey Huinker wrote: > > v21 attached. > > 0003 is the statistics changes to pg_dump, adding the options -X / -- > statistics-only, and the derivative boolean statisticsOnly. The -P > option is already used by pg_restore, so instead I chose -X because > of the

Re: remaining sql/json patches

On Mon, 8 Apr 2024 at 10:09, Amit Langote wrote: > On Mon, Apr 8, 2024 at 2:02 PM jian he > wrote: > > On Mon, Apr 8, 2024 at 11:21 AM jian he > wrote: > > > > > > On Mon, Apr 8, 2024 at 12:34 AM jian he > wrote: > > > > > > > > On Sun, Apr 7, 2024 at 9:36 PM Amit Langote > wrote: > > > > >

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

I wrote: > This works for me. One point that could stand discussion while we're > here is whether the once-a-cycle run should use the verbatim buildfarm > results or it's okay to editorialize on that typedefs list. I did a > little of the latter in da256a4a7, and I feel like we should either >

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

On Wed, 2024-05-15 at 12:56 +0530, Bharath Rupireddy wrote: > Because of this, the > buffers get flushed sooner than that of the existing COPY with > table_multi_insert AM causing regression in pgbench which uses COPY > extensively. The flushing behavior is entirely controlled by the table AM.

Re: Log details for stats dropped more than once

On Wed, May 15, 2024 at 08:04:48AM +, Bertrand Drouvot wrote: > Thanks! BTW, I just realized that adding more details for this error has > already > been mentioned in [1] (and Andres did propose a slightly different version). > > [1]: >

Re: Underscore in positional parameters?

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, but as was said, this is an older

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 11:14:14AM +0200, Alvaro Herrera wrote: > We don't use IAM anywhere, for example (it's always "index AM"), and I > don't think we'd turn "sequence AM" into SAM either, would we? SAM is not a term I've seen used for sequence AMs in the past, I don't intend to use it. TAM

Re: Why is citext/regress failing on hamerkop?

On Thu, May 16, 2024 at 9:46 AM Thomas Munro wrote: > Alright, unless anyone has an objection or ideas for improvements, I'm > going to go ahead and back-patch this slightly tidied up version > everywhere. Of course as soon as I wrote that I thought of a useful improvement myself: as far as I

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

On Wed, May 15, 2024 at 05:58:18PM +0530, Amit Kapila wrote: > I guess it could be more work if we want to enhance the test for > ERRORs other than the primary key violation. And? You could pass the ERROR string expected as argument of the function if more flexibility is wanted at some point,

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

Hi, On 2024-05-15 11:14:14 +0200, Alvaro Herrera wrote: > 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

Re: Why is citext/regress failing on hamerkop?

On Wed, May 15, 2024 at 6:00 PM Alexander Lakhin wrote: > 15.05.2024 01:26, Thomas Munro wrote: > > OK, so we know what the problem is here. Here is the simplest > > solution I know of for that problem. I have proposed this in the past > > and received negative feedback because it's a really

Re: Adding the extension name to EData / log_line_prefix

Andres Freund writes: > What portability issues do you forsee? We already look up the same symbol in > all the shared libraries ("Pg_magic_func"), so we know that we can deal with > duplicate function names. Are you thinking that somehow we'd end up with > symbol interposition or something? No,

Re: Adding the extension name to EData / log_line_prefix

Hi, On 2024-05-15 13:45:30 -0400, Tom Lane wrote: > There is one advantage over my suggestion of changing PG_MODULE_MAGIC: > if we tell people to write > >PG_MODULE_MAGIC; >#undef TEXTDOMAIN >#define TEXTDOMAIN PG_TEXTDOMAIN("hstore") > > then that's 100% backwards compatible and

Re: recovery modules

rebased -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From 046d6e4b13d3a6b15df1245f3154969f7553594d Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Wed, 15 Feb 2023 14:28:53 -0800 Subject: [PATCH v22 1/5] introduce routine for checking mutually exclusive string GUCs ---

Re: Fix PGresult leak in pg_dump during binary upgrade

> On 15 May 2024, at 20:46, Tom Lane wrote: > > 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

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

On Wed, May 15, 2024 at 04:52:19PM -0400, Robert Haas wrote: > On Wed, May 15, 2024 at 4:50 PM Tom Lane wrote: >> At this point my OCD got the better of me and I did a little >> additional wordsmithing. How about the attached? > > No objections here. +1 -- Nathan Bossart Amazon Web Services:

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

On Wed, May 15, 2024 at 4:50 PM Tom Lane wrote: > At this point my OCD got the better of me and I did a little > additional wordsmithing. How about the attached? No objections here. -- Robert Haas EDB: http://www.enterprisedb.com

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

Nathan Bossart writes: > On Wed, May 15, 2024 at 04:07:18PM -0400, Robert Haas wrote: >> How's this? > I compared this with my v1, and the only bit of information there that I > see missing in v3 is that validation step 4 only applies in the > once-per-cycle run (or if you forget to pgindent

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 4:25 PM David G. Johnston wrote: > Maybe just "match" instead of "replace_match". Well, this is just turning into a bikeshedding exercise at this point. We can generate names for this parameter all day long, but a bunch of names none of which gets more than one vote is

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

On Wed, May 15, 2024 at 04:07:18PM -0400, Robert Haas wrote: > 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

Re: add function argument names to regex* functions.

On 05/15/24 15:31, Robert Haas wrote: > On Wed, May 15, 2024 at 3:23 PM Chapman Flack wrote: >> What would be wrong with [occurrence], for consistency's sake? > > It was proposed and rejected upthread, but that's not to say that I > necessarily endorse the reasons given. Apologies for not

Re: add function argument names to regex* functions.

On Wed, May 15, 2024 at 1:19 PM Robert Haas wrote: > > So my point was: to me, N is more self-documenting than replace_at, > and less self-documenting than count or occurrence. > > If your mileage varies on that point, so be it! > > Maybe just "match" instead of "replace_match". Reading this it

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?

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

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 >

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

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

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: 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

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,

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

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

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

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

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

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

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: 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: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

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

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: 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

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

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

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: 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

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

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

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: 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: [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: [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: 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

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 >

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

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 >

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: 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

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

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

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

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

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: 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: 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

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

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

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/

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

  1   2   >