| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: pg_partition_tree crashes for a non-defined relation |
| Date: | 2019-02-28 01:45:49 |
| Message-ID: | 20190228014549.GD1617@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 27, 2019 at 03:48:08PM -0300, Alvaro Herrera wrote:
> 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.
Hmm. Going through the thread again NULL was decided to make the
whole experience consistent, now by returning nothing we would get
a behavior as consistent as when NULL is used in input, so point taken
to tune the behavior for unsupported relkinds and undefined objects.
Does the attached look fine to you?
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| partition-tree-srf.patch | text/x-diff | 1.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2019-02-28 01:59:47 | RE: Libpq support to connect to standby server as priority |
| Previous Message | Tsunakawa, Takayuki | 2019-02-28 01:05:07 | RE: reloption to prevent VACUUM from truncating empty pages at the end of relation |