Re: psql display of foreign keys - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: psql display of foreign keys
Date
Msg-id 20190228032527.GJ1617@paquier.xyz
Whole thread Raw
In response to Re: psql display of foreign keys  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: psql display of foreign keys
List pgsql-hackers
On Wed, Feb 27, 2019 at 03:37:23PM -0300, Alvaro Herrera wrote:
> It should have listed t2 too, but it doesn't.  Since these functions
> aren't supposed to work on legacy inheritance anyway, I think the right
> action is to return the empty set.  In the current version I just do
> what pg_partition_tree does, but I think we should adjust that behavior.
> I'll start a new thread about that.

Yes, that's not good.  The internal wrapper for ancestors should be
reworked.  The results of pg_partition_tree are what I would expect
them to be though?  Taking your example, t111 gets listed if listing
the trees from t1 or t2.  This seems natural to me.  I am wondering
the amount of work that it would take to actually have the function
return both relations in this case..

> +pg_partition_ancestors(PG_FUNCTION_ARGS)
> +{
> +    Oid            relid = PG_GETARG_OID(0);
> +    FuncCallContext *funcctx;
> +    ListCell  **next;
> +
> +    if (!check_rel_can_be_partition(relid))
> +        PG_RETURN_NULL();

Not returning an empty set here? ;)

I would have added tests with pg_partition_ancestors(NULL) and
pg_partition_ancestors(0) for consistency with the rest.

Except that and the ancestor tracking for inheritance, the shape of
the patch looks good to me.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: pgsql: Avoid creation of the free space map for small heaprelations, t
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: reloption to prevent VACUUM from truncating empty pages at theend of relation