On 2018-Dec-09, Tom Lane wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> ... especially in code that's highly unlikely to break once written. > > > I don't entirely buy off on the argument that it's code that's 'highly > > unlikely to break once written' though- we do add new relkinds from time > > to time, for example. Perhaps we could have these functions run just > > once per relkind. > > Well, the relevant code is likely to be "if relkind is not x, y, or z, > then PG_RETURN_NULL". If we add a new relkind and forget to consider the > function, the outcome is a NULL result that perhaps should not have been > NULL ... but a test like this won't help us notice that.
I just happened to come across the result of this rationale in pg_partition_tree() (an SRF) while developing a new related function, pg_partition_ancestors(), and find the resulting behavior rather absurd -- it returns one row with all NULL columns, rather than no rows. I think the sensible behavior would be to do SRF_RETURN_DONE() before stashing any rows to the output, so that we get an empty result set instead. alvherre=# select * from pg_partition_tree('information_schema.sequences'); relid | parentrelid | isleaf | level -------+-------------+--------+------- | | | (1 fila) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services