|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: psql display of foreign keys|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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..
> + 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.
|Next Message||Tsunakawa, Takayuki||2019-02-28 03:41:03||RE: reloption to prevent VACUUM from truncating empty pages at the end of relation|
|Previous Message||Amit Kapila||2019-02-28 03:25:12||Re: pgsql: Avoid creation of the free space map for small heap relations, t|