From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: make \d pg_toast.foo show its indices ; and, \d toast show its main table ; and \d relkind=I show its partitions (and tablespace) |
Date: | 2019-06-30 08:26:28 |
Message-ID: | alpine.DEB.2.21.1906300955550.23641@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
There are 3 independent patches associated to one thread and one CF entry.
*** About toast table v3:
Patch applies cleanly, compiles, works for me.
ISTM that the he query should be unambiguous: pg_catalog.pg_class instead
of pg_class, add an alias (eg c), use c.FIELD to access an attribute. In
its current form "pg_class" could resolve to another table depending on
the search path.
C style is broken. On "if () {", brace must be on next line. On "1 !=
PQntuples(result)", I would exchange operands.
PQclear must be called on the main path.
If the table name contains a ", the result looks awkward:
For table: "public.foo"bla"
I'm wondering whether some escaping should be done. Well, it is not done
for other simular entries, so probably this is bad but okay:-)
There are no tests:-(
*** About toast index v3
Patch applies cleanly, compiles, works for me.
There are no tests:-(
*** About the next one, v4
Patch applies cleanly, compiles. Not sure how to test it.
"switch (*PQgetvalue(result, i, 2))": I understand that relkind is a must
admit I do not like this style much, an intermediate variable would
improve readability. Also, a simple if instead of a swich might be more
appropriate, and be closer to the previous implementation.
There are no tests:-(
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2019-06-30 08:47:09 | Re: proposal - patch: psql - sort_by_size |
Previous Message | David Rowley | 2019-06-30 07:34:32 | Re: Multivariate MCV list vs. statistics target |