On Fri, Mar 6, 2020 at 11:46 AM Alexander Korotkov
wrote:
> On Fri, Mar 6, 2020 at 7:10 AM vignesh C wrote:
> > I feel your explanation sounds fair to me.
>
> Thanks.
>
> I've also revised tab-completion code. I'm going to push this if no
> objections.
So, pushed!
--
Alexander Korotkov
On Fri, Mar 6, 2020 at 7:10 AM vignesh C wrote:
> I feel your explanation sounds fair to me.
Thanks.
I've also revised tab-completion code. I'm going to push this if no objections.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, Mar 6, 2020 at 6:28 AM Alexander Korotkov
wrote:
>
> On Thu, Mar 5, 2020 at 8:34 PM vignesh C wrote:
> > On Wed, Mar 4, 2020 at 5:02 AM Alexander Korotkov
> > wrote:
> > >
> > > Hi!
> > >
> > > Thank you for the review. Revised patch is attached.
> > >
> >
> > Thanks for working on
On Thu, Mar 5, 2020 at 8:34 PM vignesh C wrote:
> On Wed, Mar 4, 2020 at 5:02 AM Alexander Korotkov
> wrote:
> >
> > Hi!
> >
> > Thank you for the review. Revised patch is attached.
> >
>
> Thanks for working on comments and providing a new patch.
> One small observation I noticed:
>
On Wed, Mar 4, 2020 at 5:02 AM Alexander Korotkov
wrote:
>
> Hi!
>
> Thank you for the review. Revised patch is attached.
>
Thanks for working on comments and providing a new patch.
One small observation I noticed:
postgres=# \*dAc* brin oid
Index access method operator classes
On 2020-Mar-04, Alexander Korotkov wrote:
> On Wed, Jan 22, 2020 at 1:33 AM Alvaro Herrera
> wrote:
> > I think I would like this feature to be in, but I'm not sure that the
> > shape is final yet. My points:
> >
> > a) I don't see any use for \dA as presented; I think the \dA+ output is
> >
Hi!
Thank you for the review. Revised patch is attached.
On Wed, Jan 22, 2020 at 1:33 AM Alvaro Herrera wrote:
> I think I would like this feature to be in, but I'm not sure that the
> shape is final yet. My points:
>
> a) I don't see any use for \dA as presented; I think the \dA+ output is
>
Hi Alexander,
On 1/21/20 5:37 PM, Alvaro Herrera wrote:
On 2020-Jan-21, Alvaro Herrera wrote:
c) it would be damn handy if \dAf (maybe \dAf+) lists the datatypes that
each opfamily has opclasses for. Maybe make the output an array, like
{int4,int8,numeric,...} Something like [*] but
On 2020-Jan-21, Alvaro Herrera wrote:
> c) it would be damn handy if \dAf (maybe \dAf+) lists the datatypes that
>each opfamily has opclasses for. Maybe make the output an array, like
>{int4,int8,numeric,...} Something like [*] but somehow make it
>prettier?
Sorry, I forgot to
I think I would like this feature to be in, but I'm not sure that the
shape is final yet. My points:
a) I don't see any use for \dA as presented; I think the \dA+ output is
useful. Therefore my preference would be that \dA presents what the
latest patch has as \dA+. I think we should
Hi Alexander,
On Mon, Sep 23, 2019 at 10:54:51PM +0300, Alexander Korotkov wrote:
> Revised patch is attached.
The commit log of the patch reads like that:
"Fix handling Inf and Nan values in GiST pairing heap comparator"
That's obviously incorrect. Do you have an updated patch? I am
moving
On Wed, Sep 18, 2019 at 5:04 PM Alvaro Herrera wrote:
> On 2019-Sep-18, Alexander Korotkov wrote:
>
> > On Tue, Sep 17, 2019 at 9:01 PM Alvaro Herrera
> > wrote:
>
> > > I think \dAf is just as critical as \dAo; the former lets you know which
> > > opfamilies you can use in CREATE INDEX, while
On 2019-Sep-18, Alexander Korotkov wrote:
> On Tue, Sep 17, 2019 at 9:01 PM Alvaro Herrera
> wrote:
> > I think \dAf is just as critical as \dAo; the former lets you know which
> > opfamilies you can use in CREATE INDEX, while the latter lets you know
> > which operators would be helped by
On Tue, Sep 17, 2019 at 9:01 PM Alvaro Herrera wrote:
> It seems strange that there's a way to display AMs, and a way to display
> ops and procs in an opfamily; but there's no way to list what opfamilies
> exist (possibly given an AM as pattern). Should we add that too? We
> had \dAf in the
It seems strange that there's a way to display AMs, and a way to display
ops and procs in an opfamily; but there's no way to list what opfamilies
exist (possibly given an AM as pattern). Should we add that too? We
had \dAf in the original submission, but that seems to have lost along
the way,
On Sat, Sep 14, 2019 at 1:45 PM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
> On Sat, Sep 14, 2019 at 10:39 AM Alexander Korotkov
> wrote:
> > On Sat, Sep 14, 2019 at 12:36 AM Alvaro Herrera
> > wrote:
> > > On 2019-Aug-06, Alexander Korotkov wrote:
> > >
> > > > Revised patch is
On Sat, Sep 14, 2019 at 10:39 AM Alexander Korotkov
wrote:
> On Sat, Sep 14, 2019 at 12:36 AM Alvaro Herrera
> wrote:
> > On 2019-Aug-06, Alexander Korotkov wrote:
> >
> > > Revised patch is attached. Changes to \dA+ command are reverted. It
> > > also contains some minor improvements.
> > >
>
On Sat, Sep 14, 2019 at 12:36 AM Alvaro Herrera
wrote:
> On 2019-Aug-06, Alexander Korotkov wrote:
>
> > Revised patch is attached. Changes to \dA+ command are reverted. It
> > also contains some minor improvements.
> >
> > Second patch looks problematic for me, because it provides index
> >
On 2019-Aug-06, Alexander Korotkov wrote:
> Revised patch is attached. Changes to \dA+ command are reverted. It
> also contains some minor improvements.
>
> Second patch looks problematic for me, because it provides index
> description alternative to \d+. IMHO, if there is something really
>
On Wed, Jul 24, 2019 at 4:59 PM Alexander Korotkov
wrote:
> On Wed, Jul 24, 2019 at 9:01 AM Andres Freund wrote:
> > Based on a quick skim of the thread - which means I most definitely
> > missed things - there's not been discussion of why we actually want to
> > add this. Who's the prospective
On Wed, Jul 24, 2019 at 9:01 AM Andres Freund wrote:
> Based on a quick skim of the thread - which means I most definitely
> missed things - there's not been discussion of why we actually want to
> add this. Who's the prospective user of this facility? And why wouldn't
> they just query
Hi!
On Wed, Jul 24, 2019 at 9:00 AM Andres Freund wrote:
> On 2019-07-23 01:57:29 +0300, Alexander Korotkov wrote:
> > It was always scary there is no way in psql to see am/opclass/opfamily
> > information rather than query catalog directly.
>
> What does make that scary?
For it's unclear why
Hi,
On 2019-07-15 22:03:31 +0300, Nikita Glukhov wrote:
> +
> +
> + \dAc[+]
> +[ class="parameter">access-method-pattern
> + [ class="parameter">input-type-pattern]]
> +
> +
> +
> +
> +Shows info index
Hi,
On 2019-07-23 01:57:29 +0300, Alexander Korotkov wrote:
> It was always scary there is no way in psql to see am/opclass/opfamily
> information rather than query catalog directly.
What does make that scary?
> I'm going to push it. Probably, someone find that commands syntax and
> output
Hi,
On 2019-07-15 22:03:31 +0300, Nikita Glukhov wrote:
> +
> +
> + \dAc[+]
> +[ class="parameter">access-method-pattern
> + [ class="parameter">input-type-pattern]]
> +
> +
> +
> +
> +Shows info index
On Mon, Jul 22, 2019 at 11:25 PM Nikita Glukhov wrote:
> Columns "Handler" and "Description" were added to \dA+.
>
> \dA [NAME] now shows only amname and amtype.
Cool!
> Also added support for pre-9.6 server versions to both \dA and \dA+.
I was going to ask about that. You got ahead of me :-)
Attached 8th version of the patches.
On 22.07.2019 15:58, Alexander Korotkov wrote:
On Mon, Jul 22, 2019 at 6:29 AM Alvaro Herrera wrote:
On 2019-Jul-21, Alexander Korotkov wrote:
I've one note. Behavior of "\dA" and "\dA pattern" look
counter-intuitive to me. I would rather expect that
On Mon, Jul 22, 2019 at 6:29 AM Alvaro Herrera wrote:
> On 2019-Jul-21, Alexander Korotkov wrote:
> > I've one note. Behavior of "\dA" and "\dA pattern" look
> > counter-intuitive to me. I would rather expect that "\dA pattern"
> > would just filter results of "\dA", but it displays different
>
On 2019-Jul-21, Alexander Korotkov wrote:
> I've one note. Behavior of "\dA" and "\dA pattern" look
> counter-intuitive to me. I would rather expect that "\dA pattern"
> would just filter results of "\dA", but it displays different
> information. I suggest rename displaying access method
On Mon, Jul 15, 2019 at 10:05 PM Nikita Glukhov wrote:
> On 01.07.2019 14:06, Thomas Munro wrote:
>
> > On Sun, Mar 31, 2019 at 2:13 PM wrote:
> >> Thanks for review.
> > Hi Sergey,
> >
> > A new Commitfest is here and this doesn't apply -- could you please
> > post a rebase?
> >
> > Thanks,
>
>
On 01.07.2019 14:06, Thomas Munro wrote:
On Sun, Mar 31, 2019 at 2:13 PM wrote:
Thanks for review.
Hi Sergey,
A new Commitfest is here and this doesn't apply -- could you please
post a rebase?
Thanks,
Attached 7th version of the patches rebased onto current master.
--
Nikita Glukhov
On Sun, Mar 31, 2019 at 2:13 PM wrote:
> Thanks for review.
Hi Sergey,
A new Commitfest is here and this doesn't apply -- could you please
post a rebase?
Thanks,
--
Thomas Munro
https://enterprisedb.com
Thanks for review.
With + it shows description:
# \dA+
List of access methods
Name |
Type | Handler| Description
+---+--+---
-
brin | index | brinhandler |
Thank you for the new version.
At Fri, 22 Mar 2019 21:29:09 +0300, Sergey Cherkashin
wrote in
> Taking into account the wishes of all the reviewers, the current
> position of the patch is as follows:
>
> The \dA command displays a list of access methods.
>
> # \dA
> List of access
Taking into account the wishes of all the reviewers, the current
position of the patch is as follows:
The \dA command displays a list of access methods.
# \dA
List of access methods
Name | Type | Handler
+---+--
brin | index |
Hi.
On 08.03.2019 7:52, Kyotaro HORIGUCHI wrote:
Hello.
At Mon, 10 Dec 2018 19:38:39 +0300, s.cherkas...@postgrespro.ru wrote in
<70e94e339dd0fa2be5d3eebec68da...@postgrespro.ru>
Here are some fixes. But I'm not sure that the renaming of columns for
the '\dAp' command is sufficiently
Hi Sergey,
On 3/8/19 8:52 AM, Kyotaro HORIGUCHI wrote:
At Mon, 10 Dec 2018 19:38:39 +0300, s.cherkas...@postgrespro.ru wrote in
<70e94e339dd0fa2be5d3eebec68da...@postgrespro.ru>
Here are some fixes. But I'm not sure that the renaming of columns for
the '\dAp' command is sufficiently laconic
Hello.
At Mon, 10 Dec 2018 19:38:39 +0300, s.cherkas...@postgrespro.ru wrote in
<70e94e339dd0fa2be5d3eebec68da...@postgrespro.ru>
> Here are some fixes. But I'm not sure that the renaming of columns for
> the '\dAp' command is sufficiently laconic and informative. If you
> have any suggestions
On Mon, Dec 10, 2018 at 07:38:39PM +0300, s.cherkas...@postgrespro.ru wrote:
> Here are some fixes. But I'm not sure that the renaming of columns for the
> '\dAp' command is sufficiently laconic and informative. If you have any
> suggestions on how to improve them, I will be very grateful.
I have
Here are some fixes. But I'm not sure that the renaming of columns for
the '\dAp' command is sufficiently laconic and informative. If you have
any suggestions on how to improve them, I will be very grateful.
Best regards,
Sergey Cherkashin.diff --git a/doc/src/sgml/catalogs.sgml
On Fri, Nov 23, 2018 at 05:13:24PM +0300, Sergey Cherkashin wrote:
> The attached patches are applied sequentially: first 0003-
> psql_add_am_info.patch, then 0003-psql_add_index_info.patch.
Thanks for doing a split. I have been looking at add_am to being with,
which is the first one in the set.
> \dA{f,p,fo,fp,oc}
> Please explain what these are.
We adhere to the following logic
f - families
fo - operators in families
fp - procedures in families
p - access method properties
oc - operator classes
> I think this is two patches -- one being the \dip/\dicp part, the
> other
> the \dA
Hello,
On 20.11.2018 16:08, s.cherkas...@postgrespro.ru wrote:
Ok, I fixed this.
I looked at the patch. It is in good shape. It compiles and tests are
passed.
I have few a questions related with throwing errors. They might be silly :)
\dAp as well as \dA command throw an error if a
On 2018-Nov-20, s.cherkas...@postgrespro.ru wrote:
> Ok, I fixed this.
Cool. I'm not sure this is a good idea: "c.relname::pg_catalog.regclass"
I would use c.oid::pg_catalog.regclass instead.
But before getting into those details, I think we should discuss the
user interface that this patch is
Ok, I fixed this.
On 2018-11-20 13:41, Alvaro Herrera wrote:
On 2018-Nov-20, s.cherkas...@postgrespro.ru wrote:
Yes, I am available to finish this patch.
I’m sorry that I hadn’t updated patch for new commitfest and I
grateful to
you for doing it and fixing some issues.
I would like to
On 2018-Nov-20, s.cherkas...@postgrespro.ru wrote:
> Yes, I am available to finish this patch.
> I’m sorry that I hadn’t updated patch for new commitfest and I grateful to
> you for doing it and fixing some issues.
> I would like to clarify which commands lack the output of the schema names?
>
Yes, I am available to finish this patch.
I’m sorry that I hadn’t updated patch for new commitfest and I grateful
to you for doing it and fixing some issues.
I would like to clarify which commands lack the output of the schema
names? Because I tried to display them for all objects that have a
On 2018-Nov-19, Michael Paquier wrote:
> On Sat, Nov 17, 2018 at 11:20:50PM -0300, Alvaro Herrera wrote:
> > Here's a rebased version, fixing the rejects, pgindenting, and fixing
> > some "git show --check" whitespace issues. Haven't reviewed any further
> > than that.
>
> Schema qualifications
On Sat, Nov 17, 2018 at 11:20:50PM -0300, Alvaro Herrera wrote:
> Here's a rebased version, fixing the rejects, pgindenting, and fixing
> some "git show --check" whitespace issues. Haven't reviewed any further
> than that.
Schema qualifications are missing in many places, and they are added
On 2018-Oct-01, Michael Paquier wrote:
> On Tue, Jul 03, 2018 at 01:25:37PM +0300, s.cherkas...@postgrespro.ru wrote:
> > diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
> > index 3ed9021..b699548 100644
> > --- a/doc/src/sgml/catalogs.sgml
> > +++
On Tue, Jul 03, 2018 at 01:25:37PM +0300, s.cherkas...@postgrespro.ru wrote:
> diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
> index 3ed9021..b699548 100644
> --- a/doc/src/sgml/catalogs.sgml
> +++ b/doc/src/sgml/catalogs.sgml
Please note that the latest patch proposed does
Following issues are solved:
\dAf[+] [AMPTRN [OPFPTRN]] list operator families of access method.
+
prints owner of operator family. (Table pg_opfamily)
\dAfp[AMPTRN [OPFPTRN]] list procedures of operator family
related
to access method (Table pg_amproc)
* Reorder "Left"/"Right"
On 22.06.2018 16:48, Sergey Cherkashin wrote:
Hello!
There are command in psql to list access methods, but there are no fast
way to look detailed info about them. So here a patch with new
commands:
Hi!
I've done a preliminary in-company review of this patch several times.
Here is my review
Hello!
There are command in psql to list access methods, but there are no fast
way to look detailed info about them. So here a patch with new
commands:
\dAp [PATTERN] list access methods with properties (Table
pg_am)
\dAf[+] [AMPTRN [OPFPTRN]] list operator families of access
54 matches
Mail list logo
