Re: Include access method in listTables output - Mailing list pgsql-hackers

From Georgios
Subject Re: Include access method in listTables output
Date
Msg-id EqMRJvjKaydzl4S4TLkR_4R1JbBmxB6aPHHxKVERhmDGMb66uzB9Iq1BYk7Go_RWdbeDBZxQ5ZFLvVUQoJX5KBfgcjUVgCduiTUZd0SypCE=@protonmail.com
Whole thread Raw
In response to Re: Include access method in listTables output  (vignesh C <vignesh21@gmail.com>)
Responses Re: Include access method in listTables output  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, June 20, 2020 3:15 PM, vignesh C <vignesh21@gmail.com> wrote:

> On Tue, Jun 16, 2020 at 6:13 PM Georgios gkokolatos@protonmail.com wrote:
>
> > > Few comments:
> > >
> > > -   if (pset.sversion >= 120000)
> > >
> > > -   appendPQExpBufferStr(&buf,
> > >
> > > -   "\n LEFT JOIN pg_catalog.pg_am am ON am.oid = c.relam");
> > >     Should we include pset.hide_tableam check along with the version check?
> > >
> >
> > I opted against it, since it seems more intuitive to have a single
> > switch and placed on the display part. A similar pattern can be found
> > in describeOneTableDetails(). I do not hold a strong opinion and will
> > gladly ament if insisted upon.
>
> I felt we could add that check as we might be including
> pg_catalog.pg_am in cases even though we really don't need it.

As promised, I gladly ament upon your request. Also included a fix for
a minor oversight in tests, they should now be stable. Finally in this
version, I extended a bit the logic to only include the access method column
if the relations displayed can have one, for example sequences.

>
> Regards,
> Vignesh
> EnterpriseDB: http://www.enterprisedb.com


Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] Remove Extra palloc Of raw_buf For Binary Format In COPY FROM
Next
From: Etsuro Fujita
Date:
Subject: Re: estimation problems for DISTINCT ON with FDW