On 2016/06/22 19:37, Ashutosh Bapat wrote:
On Wed, Jun 22, 2016 at 3:57 PM, Etsuro Fujita
    Maybe I'm confused, but I think that in the system-column case it's
    the user's responsibility to specify system columns for foreign
    tables in a local query only when that makes sense on the remote
    end, as shown in the below counter example:

    postgres=# create foreign table fv1 (a int, b int) server myserver
    options (table_name 'v1');
    postgres=# select ctid, * from fv1;
    ERROR:  column "ctid" does not exist
    CONTEXT:  Remote SQL command: SELECT a, b, ctid FROM public.v1

But a ctid, when available, would rightly get nullified when referenced
as a column of table.


What happens with the other system columns is we 0
them out locally, whether they are available at the foreign server or
not. We never try to check whether they are available at the foreign
server or not. If we use such column's column name to decide whether to
report 0 or null and if that column is not available at the foreign
table, we will get error. I think we should avoid that. Those column
anyway do not make any sense.

Agreed except for oid. I think we should handle oid in the same way as ctid, which I'll work on in the next CF.

I think the proposed idea of applying record::text explicit coercion to a whole-row reference in the IS NOT NULL condition in the CASE WHEN conversion would work as expected as you explained, but I'm concerned that the cost wouldn't be negligible when the foreign table has a lot of columns.

Best regards,
Etsuro Fujita

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

Reply via email to