| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Odd system-column handling in postgres_fdw join pushdown patch |
| Date: | 2016-04-13 18:34:22 |
| Message-ID: | 17346.1460572462@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Apr 13, 2016 at 1:36 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I tend to favor zeroes rather than NULLs, because that's what we
>> typically use to represent an invalid value of those types, and I'm
>> not aware of any current case where those values are NULL.
> In fact, see heap_attisnull.
Right, a table's system columns cannot be null at the table-scan level.
(But they could go to null above an outer join.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-04-13 18:36:14 | Re: Odd system-column handling in postgres_fdw join pushdown patch |
| Previous Message | Robert Haas | 2016-04-13 18:25:18 | Re: Odd system-column handling in postgres_fdw join pushdown patch |