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'); CREATE FOREIGN TABLE 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.
Really?
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: http://www.postgresql.org/mailpref/pgsql-hackers
