On Tue, Feb 25, 2025 at 02:42:17PM +0300, Ilia Evdokimov wrote:
> I´ve addressed all your comments on the v9 patch for updating the
> descriptions of auto_explain.log_min_duration and
> auto_explain.log_parameter_max_length. Just wanted to check if you had a
> chance to take another look. Let me kn
On 18.02.2025 01:13, Ilia Evdokimov wrote:
Thank you for reviewing! I agree with all of them. I updated patch v9
with these changes.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
Hi hackers,
I’ve addressed all your comments on the v9 patch for updating the
descriptions of auto_expl
On 18.02.2025 00:55, Nathan Bossart wrote:
On Tue, Feb 18, 2025 at 08:14:58AM +1100, Peter Smith wrote:
SUGGESTION
"-1 disables logging plans. 0 means log all plans."
+1
DefineCustomIntVariable("auto_explain.log_parameter_max_length",
"Sets the maximum length of query parameters to log
On Tue, Feb 18, 2025 at 08:14:58AM +1100, Peter Smith wrote:
> SUGGESTION
> "-1 disables logging plans. 0 means log all plans."
+1
> DefineCustomIntVariable("auto_explain.log_parameter_max_length",
> "Sets the maximum length of query parameters to log.",
> - "Zero logs no query parameters, -1
On Mon, Feb 17, 2025 at 8:50 PM Ilia Evdokimov
wrote:
>
>
> On 14.02.2025 19:47, Nathan Bossart wrote:
> > On Thu, Feb 13, 2025 at 05:01:59PM -0600, Nathan Bossart wrote:
> >> Okay, I took your suggestions in v7.
> > Committed. Thanks, David, Peter, and Daniel!
> >
>
> Hi,
>
> Maybe I'm being pic
On 14.02.2025 19:47, Nathan Bossart wrote:
On Thu, Feb 13, 2025 at 05:01:59PM -0600, Nathan Bossart wrote:
Okay, I took your suggestions in v7.
Committed. Thanks, David, Peter, and Daniel!
Hi,
Maybe I'm being picky, but in auto_explain, the parameters
log_min_duration and log_parameter_m
On Thu, Feb 13, 2025 at 05:01:59PM -0600, Nathan Bossart wrote:
> Okay, I took your suggestions in v7.
Committed. Thanks, David, Peter, and Daniel!
--
nathan
On Thu, Feb 13, 2025 at 03:50:08PM -0700, David G. Johnston wrote:
> Even if the diff has logic to it - only remove stuff from the first line,
> only add stuff to the second, it isn't a big enough gain to offset leaving
> the source ugly, IMHO.
Okay, I took your suggestions in v7.
--
nathan
>Fro
On Thu, Feb 13, 2025 at 3:18 PM Nathan Bossart
wrote:
> On Wed, Feb 12, 2025 at 04:10:53PM -0700, David G. Johnston wrote:
> > I presume it doesn't affect the actual output which just concatenates the
> > fragments together but the source placement probably should be made
> > consistent; the line
On Wed, Feb 12, 2025 at 04:10:53PM -0700, David G. Johnston wrote:
> I presume it doesn't affect the actual output which just concatenates the
> fragments together but the source placement probably should be made
> consistent; the line containing the initial default value specification
> begins its
On Wed, Feb 12, 2025 at 3:47 PM Nathan Bossart
wrote:
> Good catch. I've fixed that in v5.
>
>
I presume it doesn't affect the actual output which just concatenates the
fragments together but the source placement probably should be made
consistent; the line containing the initial default value s
On Thu, Feb 13, 2025 at 09:02:30AM +1100, Peter Smith wrote:
> One last thing...
>
> - gettext_noop("Zero logs all files. The default is -1 (turning this
> feature off)."),
> + gettext_noop("-1 disables temporary file logs. 0 means log all
> temporary files."),
>
> The first sentence could be amb
One last thing...
- gettext_noop("Zero logs all files. The default is -1 (turning this
feature off)."),
+ gettext_noop("-1 disables temporary file logs. 0 means log all
temporary files."),
The first sentence could be ambiguous. E.g. "temporary file logs"
might be interpreted as meaning logs about
> On 12 Feb 2025, at 22:04, Nathan Bossart wrote:
>
> Here is what I have staged for commit, which I intend to do within the next
> couple of days unless there is additional feedback. In v4, I've added a
> commit message, removed the changes to the ssl_crl_* parameters, and fixed
> a couple of v
Here is what I have staged for commit, which I intend to do within the next
couple of days unless there is additional feedback. In v4, I've added a
commit message, removed the changes to the ssl_crl_* parameters, and fixed
a couple of very small mistakes.
--
nathan
>From 3205f1172ac6ec2a82171bba
On Tue, Feb 11, 2025 at 11:41:51PM +0100, Daniel Gustafsson wrote:
>> On 11 Feb 2025, at 19:11, Nathan Bossart wrote:
>
>> I thought about this one a bit, and I actually came to the opposite
>> conclusion. IMHO it's reasonably obvious that an empty string means that
>> the file isn't loaded, so
> On 11 Feb 2025, at 19:11, Nathan Bossart wrote:
> I thought about this one a bit, and I actually came to the opposite
> conclusion. IMHO it's reasonably obvious that an empty string means that
> the file isn't loaded, so there's not much point in stating it in the GUC
> description. Instead,
I don't have an opinion about the ssl_crl stuff. Everything else looks
good to me.
==
Kind Regards,
Peter Smith.
Fujitsu Australia.
Thank you for the reviews.
On Mon, Feb 10, 2025 at 05:25:42PM -0700, David G. Johnston wrote:
> On Mon, Feb 10, 2025 at 4:53 PM Peter Smith wrote:
>> {"shared_memory_size_in_huge_pages", PGC_INTERNAL, PRESET_OPTIONS,
>> gettext_noop("Shows the number of huge pages needed for the main
>> share
On Mon, Feb 10, 2025 at 4:53 PM Peter Smith wrote:
> On Tue, Feb 11, 2025 at 9:25 AM Nathan Bossart
> wrote:
> >
> > On Tue, Feb 11, 2025 at 08:29:28AM +1100, Peter Smith wrote:
> > > +1 for this. Your wording examples below look good to me..
> >
> > Okay, how does this look?
> >
> > --
>
> v2 m
On Tue, Feb 11, 2025 at 9:25 AM Nathan Bossart wrote:
>
> On Tue, Feb 11, 2025 at 08:29:28AM +1100, Peter Smith wrote:
> > +1 for this. Your wording examples below look good to me..
>
> Okay, how does this look?
>
> --
v2 mostly looked good to me. Just a couple of questions.
~~~
1.
{"shared_m
On Tue, Feb 11, 2025 at 08:29:28AM +1100, Peter Smith wrote:
> +1 for this. Your wording examples below look good to me..
Okay, how does this look?
--
nathan
>From 25f62fa18e5e6ffd0fbd48e9f9bdd5474caaf23c Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 7 Feb 2025 16:06:18 -0600
Subject
On Tue, Feb 11, 2025 at 3:22 AM David G. Johnston
wrote:
>
> On Mon, Feb 10, 2025 at 9:02 AM Nathan Bossart
> wrote:
>>
>> On Mon, Feb 10, 2025 at 09:13:26AM +1100, Peter Smith wrote:
>> > +1 for improving consistency.
>>
>> Thanks for reviewing.
>>
>> > 1. IMO all places wording as "XXX means t
On Mon, Feb 10, 2025 at 9:02 AM Nathan Bossart
wrote:
> On Mon, Feb 10, 2025 at 09:13:26AM +1100, Peter Smith wrote:
> > +1 for improving consistency.
>
> Thanks for reviewing.
>
> > 1. IMO all places wording as "XXX means to YYY" should be just "XXX
> > means YYY" (e.g. remove the "to")
> >
> >
On Mon, Feb 10, 2025 at 09:13:26AM +1100, Peter Smith wrote:
> +1 for improving consistency.
Thanks for reviewing.
> 1. IMO all places wording as "XXX means to YYY" should be just "XXX
> means YYY" (e.g. remove the "to")
>
> e.g. "-1 means to wait forever." => "-1 means wait forever."
> e.g. ""-
On Sat, Feb 8, 2025 at 9:27 AM Nathan Bossart wrote:
>
> For many GUCs, special values like -1, "", etc. have some sort of special
> meaning, such as disabling the feature. While the documentation seems to
> be reasonably good about listing special values, the GUC descriptions are
> less consiste
On Wed, Sep 2, 2020 at 8:06 PM Tom Lane wrote:
> Please defend that claim. Otherwise this seems like a pretty
> random change.
I had seen that there is discrepancy in postgres --describe-config & the
value displayed from pg_settings like in the below case:
postgres=# select name,min_val, max_va
vignesh C writes:
> Postgres's describe-config option prints reset_val for int & real
> configuration parameters which is not useful as it is not updated.
Uh, what?
> Printing boot_val is better in this case.
Please defend that claim. Otherwise this seems like a pretty
random change.
On 2019-Aug-01, Corey Huinker wrote:
> From all this, I have so far concluded:
>
> 1. There is real demand to be able to easily see the basic structure of
> tables, views, and indexes in a way that strikes a balance between detail
> and clutter.
That's great. That said, I'm not opposed to a DES
>
> It seems this topic is ongoing so I've moved it to the September CF,
> but it's in "Waiting on Author" because we don't have a concrete patch
> that applies (or agreement on what it should do?) right now.
>
All recent work has been investigating the need(s) we're trying to address.
This is as
On Sun, Jun 23, 2019 at 7:34 AM Corey Huinker wrote:
>> > So what is the uptake on implementing this at the server side, ie.
>> > DESCRIBE?
>>
>> I'm pretty skeptical of this idea, unless you are willing to throw
>> away at least one and possibly both of the following goals:
It seems this topic i
>
> > So what is the uptake on implementing this at the server side, ie.
> > DESCRIBE?
>
> I'm pretty skeptical of this idea, unless you are willing to throw
> away at least one and possibly both of the following goals:
>
> 1. Compatibility with psql's existing \d behavior.
>
I don't think *compat
On Fri, Jun 21, 2019 at 05:49:43PM -0400, Alvaro Herrera wrote:
> On 2019-Jun-21, David Fetter wrote:
>
> > On Fri, Jun 21, 2019 at 05:20:54PM -0400, Alvaro Herrera wrote:
> > > On 2018-Jan-29, David Fetter wrote:
> > >
> > > > We could certainly have \d call DESCRIBE for later versions of the
>
Alvaro Herrera writes:
> On 2018-Jan-29, David Fetter wrote:
>> We could certainly have \d call DESCRIBE for later versions of the
>> server. \ commands which call different SQL depending on server
>> version have long been a standard practice.
> So what is the uptake on implementing this at the
On 2019-Jun-21, David Fetter wrote:
> On Fri, Jun 21, 2019 at 05:20:54PM -0400, Alvaro Herrera wrote:
> > On 2018-Jan-29, David Fetter wrote:
> >
> > > We could certainly have \d call DESCRIBE for later versions of the
> > > server. \ commands which call different SQL depending on server
> > > v
On Fri, Jun 21, 2019 at 05:20:54PM -0400, Alvaro Herrera wrote:
> On 2018-Jan-29, David Fetter wrote:
>
> > We could certainly have \d call DESCRIBE for later versions of the
> > server. \ commands which call different SQL depending on server
> > version have long been a standard practice.
>
> S
On 2018-Jan-29, David Fetter wrote:
> We could certainly have \d call DESCRIBE for later versions of the
> server. \ commands which call different SQL depending on server
> version have long been a standard practice.
So what is the uptake on implementing this at the server side, ie.
DESCRIBE?
-
On Sat, May 18, 2019 at 1:17 AM Sergei Kornilov wrote:
> Hello
>
> No, this is not bug. This is expected beharior of search_path setting:
> https://www.postgresql.org/docs/current/runtime-config-client.html
>
> > Likewise, the current session's temporary-table schema, pg_temp_nnn, is
> always sea
Hello
No, this is not bug. This is expected beharior of search_path setting:
https://www.postgresql.org/docs/current/runtime-config-client.html
> Likewise, the current session's temporary-table schema, pg_temp_nnn, is
> always searched if it exists. It can be explicitly listed in the path by
>
Melanie Plageman writes:
> So, I noticed that if I make a table in one schema and then a table with the
> same name in another schema that describe only shows me one of them.
Yes, that's intended, psql's \d will only show you tables that are
visible in the search path, unless you give it a qualif
Hi
> Since this is now waiting for v13, there's a bit more time to entertain
> the question of whether we'd rather have these in psql or in a new server
> command DESCRIBE [verbose] [system], and if so, whether the output of that
> would itself be query-able or not.
>
Including this feature in c
On Mon, Mar 4, 2019 at 1:45 PM Corey Huinker
wrote:
>
>>> - Tab completion for \descibe-verbose.
>>> I know that \d+ tab completion is also not there, but I think we must
>>> have tab completion for \descibe-verbose.
>>>
>>> postgres=# \describe-
>>> \describe-extension
>>> \describe-replication
>
>
> I agree with Andres and Robert. This patch should be pushed to PG13.
>
> I'll do that on March 8 unless there is a compelling argument not to.
>
>
No objection. I'll continue to work on it, though.
On 2/25/19 9:44 PM, Robert Haas wrote:
On Sat, Feb 23, 2019 at 7:19 PM Andres Freund wrote:
Sure, but it was late, and we have far more patches than we can deal
with. Many of them much much older than this.
More importantly, at least in my opinion, is that this is one of those
questions that
>
>
>> - Tab completion for \descibe-verbose.
>> I know that \d+ tab completion is also not there, but I think we must
>> have tab completion for \descibe-verbose.
>>
>> postgres=# \describe-
>> \describe-extension
>> \describe-replication-publication \describe-user-mapping
>> \describe-fo
Hi Corey,
Here is the modified patch (sample).
On Mon, Mar 4, 2019 at 7:02 PM Ibrar Ahmed wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Do
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Thanks for the patch, I have reviewed the patch and have some comments about
On Sat, Feb 23, 2019 at 7:19 PM Andres Freund wrote:
> Sure, but it was late, and we have far more patches than we can deal
> with. Many of them much much older than this.
More importantly, at least in my opinion, is that this is one of those
questions that people tend to have very strong feeling
Hi,
On 2019-02-23 19:14:27 -0500, Corey Huinker wrote:
> >
> > Given that this patch has been added to the last commitfest for v12, I
> > think we should mark it as targeting 13, so it can be skipped over by
> > people looking to get things into v12. Even leaving fairness aside, I
> > don't think
>
> Given that this patch has been added to the last commitfest for v12, I
> think we should mark it as targeting 13, so it can be skipped over by
> people looking to get things into v12. Even leaving fairness aside, I
> don't think it's likely to be ready quickly enough...
>
Obviously this patch
Hi,
On 2019-01-24 20:37:48 -0500, Corey Huinker wrote:
> Attached is a patch to add verbose \describe commands to compliment our
> existing but slightly cryptic family of \d commands.
Given that this patch has been added to the last commitfest for v12, I
think we should mark it as targeting 13, s
Attached is a patch to add verbose \describe commands to compliment our
existing but slightly cryptic family of \d commands.
The goals of this are:
- aid user discovery of \d-commands via tab completion
- make scripts and snippets slightly more self-documenting and
understandable
- save experience
On Mon, Jan 29, 2018 at 02:51:53PM +, Ryan Murphy wrote:
> >
> > >What I propose is in fact a server command, >which at least three of
> > >the other popular RDBMSs already have.
> >
> Well to actually implement it, it would probably be a client command,
> because that's what \d* are.
Why shou
>
> >What I propose is in fact a server command, >which at least three of
> >the other popular RDBMSs already have.
>
Well to actually implement it, it would probably be a client command,
because that's what \d* are. We would most likely want them implemented
the same, to avoid needless complexity
On Sat, Jan 27, 2018 at 10:54:07PM +0100, Vik Fearing wrote:
> On 01/27/2018 05:39 PM, David Fetter wrote:
> > On Fri, Jan 26, 2018 at 04:28:24PM +0100, Vik Fearing wrote:
> >> On 01/26/2018 03:49 PM, David Fetter wrote:
> >>> I propose that we do what at least MySQL, Oracle, and DB2 do and
> >>> i
On 01/27/2018 05:39 PM, David Fetter wrote:
> On Fri, Jan 26, 2018 at 04:28:24PM +0100, Vik Fearing wrote:
>> On 01/26/2018 03:49 PM, David Fetter wrote:
>>> I propose that we do what at least MySQL, Oracle, and DB2 do and
>>> implement DESCRIBE as its own command.
>> Hard pass.
>
> Would you be s
On Fri, Jan 26, 2018 at 04:28:24PM +0100, Vik Fearing wrote:
> On 01/26/2018 03:49 PM, David Fetter wrote:
> > I propose that we do what at least MySQL, Oracle, and DB2 do and
> > implement DESCRIBE as its own command.
> Hard pass.
Would you be so kind as to expand on this? "Pass" might indicate
>
> It would be about as hard to memorize \describe-schemas as it is to
> memorize \dn:
> You'd have to remember that it is "-" and not "_", that it is "describe",
> not "desc"
> and that it is "schemas", not "schema".
>
You wouldn't memorize them. You'd discover them with tab completion.
Type "
On 01/26/2018 03:49 PM, David Fetter wrote:
> I propose that we do what at least MySQL, Oracle, and DB2 do and
> implement DESCRIBE as its own command.
Hard pass.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation e
On 01/26/2018 03:49 PM, David Fetter wrote:> They are indeed terse and
cryptic, and what's worse, they're not
available to clients other than psql, so I propose that we do what at
least MySQL, Oracle, and DB2 do and implement DESCRIBE as its own
command.
Especially handy would be a variant DESCR
On Thu, Jan 25, 2018 at 08:11:00PM -0500, Corey Huinker wrote:
> Some of the discussions about making psql more user friendly (more
> tab completions help, exit, etc) got me thinking about other ways
> that psql could be more friendly, and the one that comes to mind is
> our terse but cryptic \d* c
Corey Huinker wrote:
> Some of the discussions about making psql more user friendly (more tab
> completions help, exit, etc) got me thinking about other ways that psql could
> be more friendly, and the one that comes to mind is our terse but cryptic \d*
> commands.
>
> I think it would be helpf
On 01/26/2018 02:11 AM, Corey Huinker wrote:
> Some of the discussions about making psql more user friendly (more tab
> completions help, exit, etc) got me thinking about other ways that psql
> could be more friendly, and the one that comes to mind is our terse but
> cryptic \d* commands.
>
> I th
63 matches
Mail list logo
