Thread: Include the dependent extension information in describe command.
Hi, 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? Regards, Vignesh
Attachment
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? regards, tom lane
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
On Sun, Aug 14, 2022 at 10:24 PM vignesh C <vignesh21@gmail.com> wrote: > > 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. I have updated the patch to display "Objects depending on extension" as describe extension footer. The changes for the same are available in the v2 version patch attached. Thoughts? Regards, Vignesh
Attachment
On Mon, Aug 15, 2022 at 10:09:29PM +0530, vignesh C wrote: > I have updated the patch to display "Objects depending on extension" > as describe extension footer. The changes for the same are available > in the v2 version patch attached. Thoughts? I wonder if we would be better off with a backslash command that showed the dependencies of any object. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
On Tue, Aug 16, 2022 at 9:04 PM Bruce Momjian <bruce@momjian.us> wrote: > > On Mon, Aug 15, 2022 at 10:09:29PM +0530, vignesh C wrote: > > I have updated the patch to display "Objects depending on extension" > > as describe extension footer. The changes for the same are available > > in the v2 version patch attached. Thoughts? > > I wonder if we would be better off with a backslash command that showed > the dependencies of any object. Yes, If we have a backslash command which could show the dependencies of the specified object could be helpful. Can we something like below: a) Index idx1 depend on table t1 create table t1(c1 int); create index idx1 on t1(c1); postgres=# \dD idx1 Name --------- idx1 Depends on: table t1 b) Index idx1 depend on table t1 and extension ext1 alter index idx idx1 depends on extension ext1 postgres=# \dD idx1 Name --------- idx1 Depends on: table t1 extension ext1 c) materialized view mv1 depends on table t1 create materialized view mv1 as select * from t1; postgres=# \dD mv1 Name --------- mv1 Depends on: table t1 If you are ok with this approach, I can implement a patch on similar lines. Thoughts? Regards, Vignesh