Re: Include the dependent extension information in describe command. - Mailing list pgsql-hackers

From vignesh C
Subject Re: Include the dependent extension information in describe command.
Date
Msg-id CALDaNm1imd8YFevaZD_SFrNvCY-c9AvN5p2UhACX2XV7wPaj_A@mail.gmail.com
Whole thread Raw
In response to Re: Include the dependent extension information in describe command.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Include the dependent extension information in describe command.
List pgsql-hackers
On Sun, Aug 14, 2022 at 11:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> vignesh C <vignesh21@gmail.com> writes:
> > Currently we do not include the dependent extension information for
> > index and materialized view in the describe command. I felt it would
> > be useful to include this information as part of the describe command
> > like:
> > \d+ idx_depends
> >                   Index "public.idx_depends"
> >  Column |  Type   | Key? | Definition | Storage | Stats target
> > --------+---------+------+------------+---------+--------------
> >  a      | integer | yes  | a          | plain   |
> > btree, for table "public.tbl_idx_depends"
> > Depends:
> >     "plpgsql"
>
> > Attached a patch for the same. Thoughts?
>
> This seems pretty much useless noise to me.  Can you point to
> any previous requests for such a feature?  If we did do it,
> why would we do it in such a narrow fashion (ie, only dependencies
> of two specific kinds of objects on one other specific kind of
> object)?  Why did you do it in this direction rather than
> the other one, ie show dependencies when examining the extension?

While implementing logical replication of "index which depends on
extension", I found that this information was not available in any of
the \d describe commands. I felt having this information in the \d
describe command will be useful in validating the "depends on
extension" easily. Now that you pointed out, I agree that it will be
better to show the dependencies from the extension instead of handling
it in multiple places. I will change it to handle it from extension
and post an updated version soon for this.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: bogus assert in logicalmsg_desc
Next
From: Masahiko Sawada
Date:
Subject: Re: bogus assert in logicalmsg_desc