On Tuesday, June 10, 2025, Dimitrios Apostolou wrote:
> Hello list,
>
> I have previously raised an issue on pgsql-general, where PostgreSQL is
> logging without any boundaries to the WAL directory, even if other writer
> processes can't catch up with it. It ends up with WAL partition becoming
>
On Thu, Jun 5, 2025 at 7:32 PM Robert Treat wrote:
> I'm not saying there isn't any possible use case that could be solved with
> the above (although mind my example of people running with all indexes and
> the guc always enabled; I don't think thats a sceanrio that anyone thinks
> should be reco
On Thursday, June 5, 2025, Peter Eisentraut wrote:
> On 07.04.25 02:55, Daniel Gustafsson wrote:
>
>> On 7 Apr 2025, at 02:43, David G. Johnston
>>> wrote:
>>>
>>
>> How about:
>>>
>>> + "if set to a number, overrides the
On Wed, Jun 4, 2025 at 3:17 PM Noah Misch wrote:
> On Wed, Jun 04, 2025 at 06:10:38PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
>
> > but you are right it is part of the function, not the
> > > trigger:
> >
> > > Execute deferred constraint triggers attached to
> > > non-SECURITY-
On Wed, Jun 4, 2025 at 1:45 PM Bruce Momjian wrote:
> Now, if we do want to mention it, it should be done in a way that makes
> it clear to readers whether they are affected by this change. We can
> try text like:
>
> Execute non-SECURITY-DEFINER AFTER triggers as the role that was
>
On Wed, May 21, 2025 at 10:32 AM Rustam ALLAKOV
wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: tested, failed
> Documentation:tested, failed
>
>
On Sunday, June 1, 2025, Fujii Masao wrote:
>
> On 2025/06/02 14:24, David G. Johnston wrote:
>
>> On Sunday, June 1, 2025, Fujii Masao > <mailto:masao.fu...@oss.nttdata.com>> wrote:
>>
> Also, I noticed that the "Client User" column reflects th
On Sunday, June 1, 2025, Fujii Masao wrote:
>
> In v18, the "Protocol Version" column shown by \conninfo reports only
> the major version (e.g., 3). Wouldn't it be more helpful to show the full
> version (e.g., 3.2) using PQfullProtocolVersion()? Since support for
> protocol version 3.2 was introd
On Thursday, May 29, 2025, Ashutosh Bapat
wrote:
>
> On Fri, May 16, 2025 at 1:45 PM Jelte Fennema-Nio wrote:
>
>> On Fri, 16 May 2025 at 12:24, Jacob Champion
>> wrote:
>> >
>> > On Fri, May 16, 2025 at 12:12 PM Tom Lane wrote:
>> > > That outcome seems entirely horrible to me. If you want to
On Thursday, May 29, 2025, Dias Thomas wrote:
> Hi all,
> if 2 records per second, add speed, 4 gb ram, 1 index, is it
> faster than postgres?
>
>
Why didn’t you just reply to the people who answered you on -general when
you asked this same “question”? This is a list for discussing the
de
On Thu, May 29, 2025 at 6:43 AM Robert Haas wrote:
>
> Point being: this
> feature will need to be fixed in some way that avoids further
> expanding the set of things that a superuser must not ever do for fear
> of giving away their privileges accidentally, or else it will need to
> be reverted.
Recent discussion led me to realize we are also contrary to the SQL
Standard here. v3 updates the Commit reference page to reflect this fact.
Leaving ready-to-commit.
David J.
From 9e19152958130f7610feab7983221aace7abfe20 Mon Sep 17 00:00:00 2001
From: "David G. Johnston"
Date: W
On Tue, May 27, 2025 at 3:08 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > psql has zero awareness of pgbouncer or any other non-PostgreSQL server
> you
> > might be able to point it to and establish a successful connection. The
> > lack of a w
On Tue, May 27, 2025 at 11:41 AM Shaik Mohammad Mujeeb <
mujeeb...@zohocorp.com> wrote:
> After the commit cf0cab868a, introduced in PG15, I noticed that when
> connecting to the 'pgbouncer' database via Pgbouncer, the following warning
> is shown:
>
> psql (17.2, server 1.20.1/bouncer)
> WARNING:
On Tue, May 27, 2025 at 11:15 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> While reading our documentation about pseudo-types [1] I noticed that it
> says:
>
> """
> anyelement - Indicates that a function accepts any data type
> anyarray - Indicates that a function accepts any array
On Sun, May 25, 2025 at 7:52 PM Srinath Reddy Sadipiralla <
srinath2...@gmail.com> wrote:
> 1) On top of OP's patch I added support to warn if the prefix of custom
> GUC is invalid,for valid questions such as "How do you know that's a bogus
> prefix? It could perfectly well be a fully valid setti
On Saturday, May 24, 2025, jian he wrote:
> On Sat, May 24, 2025 at 2:39 PM Feike Steenbergen
> wrote:
> >
> > The loophole is this:
> >
> > - the generated virtual column can use a user-defined function
> > - when running SELECT against that column by a superuser
> > the function is called wi
On Thursday, May 22, 2025, Amit Kapila wrote:
> On Sat, May 3, 2025 at 9:33 PM David G. Johnston
> wrote:
> >
> > While responding to a "our documentation is buggy" complaint I got
> annoyed in my attempt to reproduce the behavior by having to surgically
> copy
On Thu, May 22, 2025 at 8:43 AM Shaik Mohammad Mujeeb <
mujeeb...@zohocorp.com> wrote:
> I do understand that not everyone may prefer seeing such warnings during
> PG server restart. To address this, we could introduce a new GUC (perhaps
> named *warn_on_unregistered_guc_prefix*), which defaults t
On Thu, May 22, 2025 at 1:20 PM Greg Sabino Mullane
wrote:
> On Thu, May 22, 2025 at 12:45 PM Tom Lane wrote:
>
>> > "lpgsql.bogus = 1" .
>>
>> [ shrug... ] How do you know that's a bogus prefix? It could perfectly
>> well be a fully valid setting for an extension that
>> the installation doesn
On Wednesday, May 21, 2025, Shaik Mohammad Mujeeb
wrote:
>
> Currently, if there's a typo in an extension name while adding a GUC to
> postgresql.conf, PostgreSQL server starts up silently without any warning.
>
Because any such setting name is perfectly valid (it serves as a
placeholder) and whe
On Monday, May 19, 2025, Tatsuo Ishii wrote:
> I have observed cases where a cfbot entry fails without clear reason
> [1]. Even if the patch just modifies comments, it has failed in some
> cfbot test. In this case we could easily guess that master branch
> might have problems at the time when the
On Thu, May 15, 2025, 19:28 Peter Smith wrote:
>
>
> doesn't help bulk execution at all because the result gets in the way
> so you'll still end up surgically copying each SELECT. Since it fixes
> nothing I assumed you just commented the SELECT prompts for
> consistency with the other ones, right
On Thursday, May 1, 2025, Bruce Momjian wrote:
>
>
> I will continue improving it until beta 1, and until the final release.
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
>
Should all columns removed from system views and/or catalogs be listed in
“Migration” or is there
On Monday, May 12, 2025, Bruce Momjian wrote:
>
>
> Yeah, you could name the constraint
> "Custom_error_message_when_the_condition_is_not_met." and then just
> convert underscore to spaces and display that to the user.
>
>
The 63 byte limit seems much more likely to be a factor if the name has to
On Saturday, May 10, 2025, Miguel Ferreira
wrote:
> ALTER TABLE table_name
>
> ADD CONSTRAINT constraint_name
>
> CHECK (condition)
>
> MESSAGE 'Custom error message when the condition is not met.';
>
>
I’m seeing some value here but, odds are, there is not enough obvious
benefit or design to con
On Wed, May 7, 2025 at 11:41 PM David Rowley wrote:
> On Thu, 8 May 2025 at 15:23, David G. Johnston
> wrote:
> > Not liking the proposal, not sure it is even correct. Somehow "children
> of inheritance parent tables" are omitted.
>
> I don't see the quote
On Wed, May 7, 2025 at 4:15 PM David Rowley wrote:
> In [1] there's a bug report about ALTER TABLE ... ALTER COLUMN SET
> (n_distinct = N) not working for partitioned tables. Of course, you
> need to use n_distinct_inherited for partitioned tables, but the docs
> don't say that.
>
> I went throug
On Monday, April 28, 2025, Steve Chavez wrote:
>
> 1. Do `grant evtrig_owner to member with inherit false`, then `member`
> will not be able to drop the event trigger.
>
I think they can still use set role…
After getting my head around this, and re-reading what Tom said, I think
you have the gr
On Monday, May 5, 2025, Robert Haas wrote:
> On Thu, May 1, 2025 at 2:22 PM Robert Haas wrote:
> > > The other approach would be to do what we do for the role options and
> just specify everything explicitly in the dump. The GUC is only a default
> specifier so let's not leave room for defaults
On Sun, May 4, 2025 at 8:45 PM Nisha Moond wrote:
> Attached is the patch implementing the above proposed solution.
> Reviews and feedback are most welcome.
>
I feel like this is just papering over the issue - which is that these two
drop functions are being used for multiple differently named
p
On Saturday, May 3, 2025, Masahiko Sawada wrote:
> On Sat, May 3, 2025 at 7:42 AM David G. Johnston
> wrote:
> >
> > On Saturday, May 3, 2025, Masahiko Sawada wrote:
> >
> >>
> >> I think that we need to ensure that if users specify text/csv/binary
>
On Sat, May 3, 2025 at 12:08 PM Tanin Na Nakorn wrote:
> 3. Is it possible to patch this into the version 16 as well as the version
> 17 and latest main branch? Because I use v16.
>
>
New features are never back-ported into prior versions. Feature freeze for
v18 just happened meaning any new fea
preferable.
David J.
From 6a21091d5ce058cb68ac23f49641e1db5069d5de Mon Sep 17 00:00:00 2001
From: "David G. Johnston"
Date: Sat, 3 May 2025 08:41:47 -0700
Subject: [PATCH] doc: Make logical replication examples executable in bulk and
legal sgml.
The output command tags are not useful information for these exampl
On Saturday, May 3, 2025, Masahiko Sawada wrote:
> I think that we need to ensure that if users specify text/csv/binary
> the built-in formats are always used, to keep backward compatibility.
That was my original thinking, but it’s inconsistent with how functions
behave today. We don’t promis
On Friday, May 2, 2025, Masahiko Sawada wrote:
>
> I'm concerned about allowing multiple 'text' format implementations
> with identical names within the database, as this could lead to
> considerable confusion. When users specify 'text', it would be more
> logical to guarantee that the built-in '
On Thursday, May 1, 2025, Masahiko Sawada wrote:
>
> In light of these concerns, I've been contemplating alternative
> interface designs. One promising approach would involve registering
> custom copy formats via a C function during module loading
> (specifically, in _PG_init()). This method woul
On Wed, Apr 30, 2025 at 1:29 PM Tom Lane wrote:
> But don't we need to add
createrole_self_grant to the set of GUCs that pg_dump[all]
> resets in the emitted SQL?
>
>
The other approach would be to do what we do for the role options and just
specify everything explicitly in the dump. The GUC is
On Tuesday, April 29, 2025, songjinzhou
wrote:
> Dear hackers, here is a libpq function: PQapplicationname(), I think it
> may be of some use.
>
You really should provide at least one reasoned use case for why this
should exist.
>
> Looking forward to your reply, thank you.
>
>
This isn’t even
On Tuesday, April 22, 2025, David G. Johnston
wrote:
> On Tuesday, April 22, 2025, David G. Johnston
> wrote:
>
>> On Tuesday, April 22, 2025, Steve Chavez wrote:
>>
>>> > alter event trigger command which doesn’t need to be exercised here
>>>
>&g
On Tuesday, April 22, 2025, David G. Johnston
wrote:
> On Tuesday, April 22, 2025, Steve Chavez wrote:
>
>> > alter event trigger command which doesn’t need to be exercised here
>>
>> That part does need to be tested, I modified
>> `AlterEventTriggerOwner_inte
On Tuesday, April 22, 2025, Steve Chavez wrote:
> > alter event trigger command which doesn’t need to be exercised here
>
> That part does need to be tested, I modified `AlterEventTriggerOwner_internal`
> to allow altering owners to regular users. Before it was only restricted to
> superusers.
>
On Tuesday, April 22, 2025, Peter Smith wrote:
> Hi,
>
> While re-reading documentation about logical replication of generated
> columns, I came across this paragraph in the CREATE PUBLICATION ...
> FOR TABLE description [1].
>
>
> When a column list is specified, only the named columns are
On Monday, April 21, 2025, David Rowley wrote:
>
> Does anyone have any opinion on the wording I'm proposing in the attached?
>
I like it. It removes the problematic wording and moves the reference to
—all closer to the front to aid in skimming.
David J.
On Sunday, April 20, 2025, Steve Chavez wrote:
> > Also, this looks unconventional…
> > EventTriggerCacheItem *item = (EventTriggerCacheItem*) lfirst_oid(lc);
>
> Just noticed the mistake there, I would have expected a compilation error.
> New patch attached with the following change:
>
> Event
On Sunday, April 20, 2025, Steve Chavez wrote:
>
> - A new file event_trigger_nosuper.sql is added for the new tests
>
Expected output for the new script was not included in the commit.
Also, this looks unconventional…
EventTriggerCacheItem *item = (EventTriggerCacheItem*) lfirst_oid(lc);
Da
On Sun, Mar 16, 2025 at 8:33 PM Peter Smith wrote:
> Thanks for your suggestions. At this point option (1) is looking most
> attractive. Probably, I will just withdraw the CF entry soon unless
> there is some new interest. Just chipping away fixing a few places
> isn't going to achieve the consis
On Fri, Apr 11, 2025 at 5:19 PM Sami Imseih wrote:
> > WFM. Though is there a reason to avoid adding the "why" of the
> exception for n_mod_since_analyze?
>
> I did think about that. I thought it will be understood that since
> this is a field that deals with ANALYZE,
> it will be understood tha
On Fri, Apr 11, 2025 at 12:33 PM Sami Imseih wrote:
>
> > I'm also thinking to reword n_tup_upd, something like:
> >
> > Total number of rows updated. Subsets of these updates are also tracked
> in n_tup_hot_upd and n_tup_newpage_upd to facilitate performance monitoring.
>
> I think the current
On Friday, April 11, 2025, Tom Lane wrote:
> jian he writes:
> > CREATE TABLE gtest1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
> > CREATE VIEW gtest1v AS SELECT * FROM gtest1;
> > ALTER VIEW gtest1v ALTER COLUMN b SET DEFAULT 100;
>
> > INSERT INTO gtest1v VALUES (8, DEFAULT) returning
On Sun, Feb 9, 2025 at 2:11 AM Pavel Luzanov
wrote:
>
> I don't understand from new commitfest transition guidance
> what to do with status of commitfest entry in this case.
> May be it needs to be closed. And in a case I will be able to propose
> a new version, I will open a new entry.
>
> The c
On Thu, Apr 10, 2025 at 5:38 PM Sami Imseih wrote:
> > On Fri, 11 Apr 2025 at 02:01, Sami Imseih wrote:
> > > I created an entry for the July CF
> > > https://commitfest.postgresql.org/patch/5691/
> > >
> > > ... and I realized I forgot to include David's code comment patch
> yesterday,
> > > Re
On Wednesday, April 9, 2025, Sami Imseih wrote:
>
> In other words, the reason n_ins_since_vacuum was introduced is to freeze
> (committed) rows, so it should not need to track dead rows to do what it
> intends
> to do.
>
n_ins_since_vacuum was introduced to indicate how many tuples a vacuum
wou
On Thursday, April 10, 2025, Kirill Reshke wrote:
> On Thu, 10 Apr 2025 at 20:07, Fujii Masao
> wrote:
> >
> >
> >
> > On 2025/04/09 19:24, Kirill Reshke wrote:
> > > On Wed, 9 Apr 2025 at 14:45, Fujii Masao
> wrote:
> > >>
> > >>
> > >>
> > >> On 2025/04/09 18:25, Kirill Reshke wrote:
> > >>>
On Fri, Apr 4, 2025 at 5:19 AM Heikki Linnakangas wrote:
> On 19/10/2024 23:11, David G. Johnston wrote:
> > diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
> > index 934ef5e469..4478d0aa91 100644
> > --- a/doc/src/sgml/config.sgml
> > +++ b/doc/src/sg
On Thu, Apr 10, 2025 at 9:00 AM Tom Lane wrote:
> [ moving to -hackers ]
>
> Adrian Klaver writes:
> > On 4/10/25 05:22, Tefft, Michael J wrote:
> >> We have set log_hostname ON and we get hostname reported – but we do
> not
> >> get IP address. We would like to capture both.
> >> Is there a way
On Wed, Apr 9, 2025, 12:56 Sami Imseih wrote:
>
> What I am saying is n_ins_since_vacuum should not account for aborted
> inserts.
>
It does and from what I can see it should. You need to explain why it
should not. More importantly, convincingly enough to change five year old
behavior.
You sh
On Wednesday, April 9, 2025, Sami Imseih wrote:
>
> > What is the use case for that behavior? Perhaps you have one, but until
> you make it explicit, it is hard for others to get behind your proposal.
>
> The point is to ensure that the pg_stats fields that autovacuum uses
> are supplied the cor
On Wed, Apr 9, 2025 at 1:30 PM Sami Imseih wrote:
> >> What I am saying is n_ins_since_vacuum should not account for aborted
> inserts.
> >
> > It does and from what I can see it should. You need to explain why it
> should not. More importantly, convincingly enough to change five year old
> beh
On Wed, Apr 9, 2025, 12:39 Sami Imseih wrote:
>
> They will differ because n_tup_ins keeps increasing, while
> n_ins_since_vacuum is
> reset after a vacuum. The issue I see is that n_ins_since_vacuum should
> only
> reflect the number of newly inserted rows that are eligible for
> freezing, as de
On Wed, Apr 9, 2025, 11:57 Sami Imseih wrote:
> > Forget original purpose, is there presently a bug or not?
>
> Yes, there is a bug. Accounting rows inserted as part of an aborted
> transaction in
> n_ins_since_vacuum is not correct, since the same rows are being
> accounted for with n_dead_tup.
On Wed, Apr 9, 2025 at 11:32 AM Sami Imseih wrote:
> The purpose of b07642dbcd8d is to trigger autovacuum for append only/mainly
> workloads that don't generate dead tuples.
>
>
Why does counting or not counting the dead tuples matter? Forget original
purpose, is there presently a bug or not? B
On Sun, Apr 6, 2025 at 2:52 PM Daniel Gustafsson wrote:
>
> Looking at the other variables they tend to use "if set, then" so we should
> probably stick to that for this as well? Something like the below perhaps?
>
> HELP0(" WATCH_INTERVAL\n"
> - "number of seconds \
On Sun, Apr 6, 2025 at 4:30 AM jian he wrote:
>
> CREATE FUNCTION test_copy_format(internal)
> RETURNS copy_handler
> AS 'MODULE_PATHNAME', 'test_copy_format'
> LANGUAGE C;
> src/backend/commands/copy.c: ProcessCopyOptions
> if (strcmp(fmt, "text") == 0)
>
On Mon, Mar 24, 2025 at 9:00 AM Álvaro Herrera
wrote:
> Hello
>
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff). That would require
> no new mechanism.
>
>
That reloption is already an enum and there is no GUC to defer to when the
va
On Fri, Mar 21, 2025 at 10:21 AM Tom Lane wrote:
> Robert Haas writes:
> > However, I'm a bit concerned about the overall premise of the patch
> > set. It feels like it is moving something that really ought to happen
> > at optimization time back to parse time. I have a feeling that's going
> >
On Saturday, March 29, 2025, Kirill Reshke wrote:
> On Sat, 29 Mar 2025 at 09:47, jian he wrote:
> >
> > will use {table_beginscan, table_scan_getnextslot, table_endscan}
> > to output the data.
> > but views don't have storage, table_beginscan mechanism won't work.
> >
> > so i don't think this
On Wed, Nov 13, 2024 at 1:11 PM Corey Huinker
wrote:
> The following is step-by-step logic.
>>
>>
> The end result (one file per section) seems good to me.
>
> I suspect that reviewer burden may be the biggest barrier to going
> forward. Perhaps breaking up the changes so that each new sect1 file
On Sat, Mar 29, 2025 at 11:56 AM Andrew Dunstan wrote:
> I don't believe that the premise supports the conclusion.
>
>
> Regardless, I do support this patch and probably any similar ones proposed
in the future. Do you have an opinion on that?
David J.
On Thu, Mar 20, 2025 at 11:13 AM Nathan Bossart
wrote:
>
> How does something like this look for the comment?
>
> /*
> * isset_offset is an optional offset of a field in the result
> struct
> * that stores whether the value is explicitly set for the
> relation or
>
On Thu, Mar 20, 2025 at 8:18 AM Nathan Bossart
wrote:
> Committed.
>
>
We added isset_offset to the public struct to introduce this new general
behavior of tracking whether any table reloption has been set (not just
vacuum_truncate) without any comments.
I get the need for this kind of logic, si
Hi.
Having been in filelist.sgml a bit recently I've noticed that the original
alphabetical ordering of the entities therein hasn't been adhered to.
Partly, I suspect, because there is no guidance about these files and how
they are organized. The attached puts things back into alphabetical order
On Friday, March 28, 2025, Masahiko Sawada wrote:
>
>
> One problem in the following chunk I can see is:
>
> + qualified_format = stringToQualifiedNameList(format, NULL);
> + DeconstructQualifiedName(qualified_format, &schema, &fmt);
> + if (!schema || strcmp(schema,
On Tue, Apr 1, 2025 at 6:15 AM Marcos Pegoraro wrote:
> Em ter., 1 de abr. de 2025 às 02:00, David G. Johnston <
> david.g.johns...@gmail.com> escreveu:
>
> Wouldn't it be good to add the use of parentheses using posix ? It's
> useful and rarely documen
On Tue, Apr 1, 2025 at 6:52 AM vignesh C wrote:
>
> We are not changing the existing behavior. However, since copying data
> from large tables can take a significant amount of time, would it be
> helpful to add a cautionary note advising users to refresh the
> materialized view before running cop
On Mon, Mar 31, 2025 at 8:13 PM jian he wrote:
> On Mon, Mar 31, 2025 at 11:27 PM Fujii Masao
>
> >
> > The copy.sgml documentation should clarify that COPY TO can
> > be used with a materialized view only if it is populated.
> >
> "COPY TO can be used only with plain tables, not views, and does
On Mon, Mar 31, 2025 at 9:12 PM jian he wrote:
> On Tue, Apr 1, 2025 at 6:22 AM David G. Johnston
> wrote:
> >
> > On Tue, Mar 18, 2025 at 9:04 PM jian he
> wrote:
> >>
> >>
> >> new patch attached.
> >>
> >
> > I've d
warranted; having Pattern Matching be required
reading to make that connection seems undesirable.
David J.
From b2f64615da9522427a2e2662b1d060ffed97088c Mon Sep 17 00:00:00 2001
From: "David G. Johnston"
Date: Mon, 31 Mar 2025 14:32:12 -0700
Subject: [PATCH 1/2] v3 0001 substring
---
On Mon, Mar 31, 2025 at 11:52 AM Masahiko Sawada
wrote:
> On Sat, Mar 29, 2025 at 9:49 AM David G. Johnston
> wrote:
> >
> > On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
> >>
> >>
> >> The attached v39 patch set uses the followings:
> &
On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
>
> > ---
> > +static const CopyFromRoutine CopyFromRoutineTestCopyFormat = {
> > +.type = T_CopyFromRoutine,
> > +.CopyFromInFunc = CopyFromInFunc,
> > +.CopyFromStart = CopyFromStart,
> > +.CopyFromOneRow = Copy
On Sat, Mar 29, 2025 at 12:27 PM Kirill Reshke
wrote:
> On Sat, 29 Mar 2025 at 19:59, David G. Johnston
> wrote:
> > Regardless, I do support this patch and probably any similar ones
> proposed in the future. Do you have an opinion on that?
> >
>
> I do also support
On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
>
> The attached v39 patch set uses the followings:
>
> 0001: Create copyto_internal.h and change COPY_XXX to
> COPY_SOURCE_XXX and COPY_DEST_XXX accordingly.
> (Same as 1. in your suggestion)
> 0002: Support custom format for both C
On Sat, Mar 29, 2025 at 9:06 AM Andrew Dunstan wrote:
>
> On 2025-03-29 Sa 10:40 AM, David G. Johnston wrote:
>
> On Saturday, March 29, 2025, Kirill Reshke wrote:
>
>> On Sat, 29 Mar 2025 at 09:47, jian he
>> wrote:
>> >
>> > will use {table_beg
On Sat, Mar 29, 2025 at 1:57 AM Sutou Kouhei wrote:
> * I still think that someone may don't like defining COPY
> handlers for built-in formats. If we don't define COPY
> handlers for built-in formats finally, we can just drop
> 0004.
>
We should (and usually do) dog-food APIs when reason
On Mon, Mar 24, 2025 at 10:27 AM Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 20:09:23 MSK пользователь Nathan
> Bossart написал:
>
> > > You've just changed the whole engine, for what is seems to be an
> > > exceptional case, that can be solved via existing means.
> > I hav
On Thu, Mar 27, 2025 at 11:03 AM Renan Alves Fonseca
wrote:
> On Thu, Mar 27, 2025 at 5:38 PM Robert Haas wrote:
> > It's not a problem if UNION ALL is used within the initial_query and
> > it's not a problem if UNION ALL is used within the iterated_query. But
> > you can't apply ORDER BY to the
On Fri, Mar 21, 2025 at 1:55 PM Andres Freund wrote:
> Hi,
>
> I was trying to write some docs for an AIO related view. As part of that I
> noticed that we referenced I/O a lot, but never defined it as an acronym or
> had it in the glossary. While adding those I got somewhat confused by
> things
On Thu, Mar 27, 2025 at 9:02 AM Renan Alves Fonseca
wrote:
> So, do we support the ORDER BY in a recursive query or not?
>
Apparently we do. The "in" recurses.
If the answer is yes, I suggest one of the following modifications:
>
1. Change the error message to something like "ORDER BY at the t
On Wednesday, March 26, 2025, Tom Lane wrote:
> jian he writes:
> > the attached patch is to implement $subject.
>
> Why would this be a good idea? I don't see any principled fallback
> definition of the column. (No, "NULL" is not that.) Certainly we
> should support ALTER TABLE DROP COLUMN,
On Wed, Mar 26, 2025 at 6:34 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
>> I pondered mentioning the 2s interval but the environment variable itself
> doesn't have a default, it's either set or unset which determines whether
> it provides the de
On Wed, Mar 26, 2025 at 2:11 AM Daniel Gustafsson wrote:
> On 26 Mar 2025, at 04:52, David G. Johnston
> wrote:
> On Tue, Mar 25, 2025 at 8:07 PM Kyotaro Horiguchi
> wrote:
>
>
> I came across the following help message added in commit 1a759c83278:
>>
>>
On Wed, Mar 26, 2025 at 10:29 AM Nikolay Shaplov wrote:
> The only thing I am asking for: please keep code consistent. Better keep
> reloption core the way it was, but if it is not possible, then keep it
> consistent then.
>
Consistency at the expense of all else is a debatable position that wil
On Wed, Mar 26, 2025 at 9:14 AM Nathan Bossart
wrote:
> FWIW one of the big reasons I didn't proceed with the enum approach
initially is because I worried that I'd end up in a similar discussion
> about how terrible _that_ approach is. When I look at that patch [0], I
> genuinely wonder if folk
On Wed, Mar 26, 2025 at 8:41 AM Robert Haas wrote:
> Nathan has already had to spend a significant amount of time engaging
with this thread over what I think should be a complete non-event, and
> will probably have to spend more, and all that takes away from time
> that could, for example, be sp
On Wed, Mar 26, 2025 at 7:42 AM Robert Haas wrote:
> On Wed, Mar 26, 2025 at 10:17 AM David G. Johnston
> wrote:
> > The argument being made is that the enum patch adheres to established
> practices; and when adding new code that new code is encouraged to adhere
> to ho
On Wednesday, March 26, 2025, Robert Haas wrote:
>
> But we also decide things by providing reasons that other people can
> engage with intellectually, and I still say you're not really doing
> that. You're just saying you like X better than Y, but without really
> giving any reason that anybody
Mon Sep 17 00:00:00 2001
From: "David G. Johnston"
Date: Tue, 25 Mar 2025 23:03:41 -0700
Subject: [PATCH] doc: add local TOC to psql reference page
---
doc/src/sgml/ref/psql-ref.sgml | 63 --
1 file changed, 52 insertions(+), 11 deletions(-)
diff --git
On Tue, Mar 25, 2025 at 8:07 PM Kyotaro Horiguchi
wrote:
> Hello,
>
> I came across the following help message added in commit 1a759c83278:
>
> + HELP0(" WATCH_INTERVAL\n"
> + "number of seconds \\watch by default waits between
> executing the query buffer\n");
>
> It t
On Mon, Mar 24, 2025 at 11:45 AM Nathan Bossart
wrote:
> On Mon, Mar 24, 2025 at 09:03:11PM +0300, Nikolay Shaplov wrote:
> > В письме от понедельник, 24 марта 2025 г. 20:48:29 MSK пользователь
> Nathan
> > Bossart написал:
> >
> >> For the sake of discussion, here is what the enum approach would
On Mon, Mar 24, 2025 at 9:41 AM Nathan Bossart
wrote:
> TBH I'm not understanding the pushback for adding a way to determine
> whether the storage parameter is actually set. It's very simple, and it
> seems like it could be useful elsewhere.
IMO this is superior to using sentinel values for th
1 - 100 of 1237 matches
Mail list logo
