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,
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
>
> 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
>
> > 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
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
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
> > >
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.
>
>
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
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
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
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
>>>
>
>
> 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
>>
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
>
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
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
>
> 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
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,
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
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
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
> >>>
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
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:> 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
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*
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
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
35 matches
Mail list logo
