On Fri, Jul 28, 2017 at 8:12 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
> On 2017/07/26 22:39, Robert Haas wrote:
>> So the first part of the change weakens the assertion that a 'ctid' or
>> 'wholerow' attribute will always be present by saying that an FDW may
>> instead have other attributes sufficient to identify the row.
> That's right.
>> But
>> then the additional sentence says that there will be a 'wholerow'
>> attribute after all.  So this whole change seems to me to be going
>> around in a circle.
> What I mean by the additional one is: if the result table that is a foreign
> table has a row-level UPDATE/DELETE trigger, a 'wholerow' will also be
> present.  So, if the result table didn't have the trigger, there wouldn't be
> 'whole-row', so in that case it could be possible that there would be only
> attributes other than 'ctid' and 'wholerow'.

I think maybe something like this would be clearer, then:

      * Initialize the junk filter(s) if needed.  INSERT queries need a filter
      * if there are any junk attrs in the tlist.  UPDATE and DELETE always
-     * need a filter, since there's always a junk 'ctid' or 'wholerow'
-     * attribute present --- no need to look first.
+     * need a filter, since there's always at least one junk attribute present
+     * --- no need to look first.  Typically, this will be a 'ctid'
+     * attribute, but in the case of a foreign data wrapper it might be a
+     * 'wholerow' attribute or some other set of junk attributes sufficient to
+     * identify the remote row.
      * If there are multiple result relations, each one needs its own junk
      * filter.  Note multiple rels are only possible for UPDATE/DELETE, so we

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to