Re: psql display of foreign keys

v9 attached; this one's final AFAICT.

On 2019-Mar-25, Peter Eisentraut wrote:

> relispartition was added in PG10, so the conditional in
> describeOneTableDetails() seems wrong.

Hmm, yeah, we weren't using it anyway (since we can only use the new
display with pg_partition_ancestors which is new in pg12), but I guess
you have a point that this could confuse somebody in the future.

> In the older branches of that same function, I'd prefer writing
> 
>     false AS relispartition
> 
> for clarity.

Yeah, some previous commits in that area have added "false" flags here
and there without adding aliases.  We should fix those sometime.  And
also the new "amname" output column is conditional on the version number
and changes column numbering for any column that appears afterwards ...
that one definitely deserves a "NULL as amname" in the older branches.

I changed some code to use PQfnumber() the way pg_dump does it; that
code's support for back-branch compatibility is much more battle-tested
than psql's and I trust that to be more maintainable.  In fact, my
motivation for doing it that way is that I found psql's way to be
confusing.

> Some of the other queries could also use some column aliases, like
> 
>     conrelid = '%s'::pg_catalog.regclass AS isroot (?)
> 
> or
> 
>     pg_catalog.pg_get_constraintdef(oid, true) AS condef
> 
> (as in the other branch).

Agreed, added.

> A test case for the incoming foreign key display would be nice, as that
> was the original argument for the patch.

Agreed, added.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services