Re: psql display of foreign keys
От | Michael Paquier |
---|---|
Тема | Re: psql display of foreign keys |
Дата | |
Msg-id | 20190228032527.GJ1617@paquier.xyz обсуждение исходный текст |
Ответ на | Re: psql display of foreign keys (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: psql display of foreign keys
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: