RE: Using a different column name in a foreign table - Mailing list pgsql-general

From Alanoly Andrews
Subject RE: Using a different column name in a foreign table
Date
Msg-id YQXPR01MB30002447A51207071D002993AB5B9@YQXPR01MB3000.CANPRD01.PROD.OUTLOOK.COM
Whole thread Raw
In response to RE: Using a different column name in a foreign table  (Alanoly Andrews <alanolya@invera.com>)
Responses Re: Using a different column name in a foreign table  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
Following up on my previous message, there was a related problem with FT definitions for which I have a workaround. It seems that the new column_name after "options" in an FT definition cannot be in upper case. See below:
 
When I define a foreign table like below, I get an error in the subsequent select statement:
 
create foreign table scvmgl_rec (
MGL_CLNT_HOST_NM char(15) options (column_name 'MSG_CLNT_HOST_NM'))
server pglpolaris12018
options (schema_name 'informix', table_name 'sctmsg_rec');
 
ai01pr00=# select * from scvmgl_rec;
ERROR:  column "MSG_CLNT_HOST_NM" does not exist
CONTEXT:  Remote SQL command: SELECT "MSG_CLNT_HOST_NM" FROM informix.sctmsg_rec
 
But when I define the FT as below, there is no error in the subsequent "select".
 
create foreign table scvmgl_rec (
mgl_clnt_host_nm char(15) options (column_name 'msg_clnt_host_nm'))
server pglpolaris12018
options (schema_name 'informix', table_name 'sctmsg_rec');
 
So, apparently postgres transmits the remote query with double quotes around the upper-case column name; and such a query comes back with "column does not exist". But a double quote around a lower-case column name does not produce the error.
 
Is this a bug that needs to be fixed? I always thought that table names and column names were case-insensitive with regard to SQL's.
 
A.A.
 
-----Original Message-----
From: Alanoly Andrews
Sent: Friday, January 21, 2022 12:03 PM
To: Tom Lane <tgl@sss.pgh.pa.us>; Guillaume Lelarge <guillaume@lelarge.info>; Adrian Klaver <adrian.klaver@aklaver.com>
Cc: pgsql-general@lists.postgresql.org
Subject: RE: Using a different column name in a foreign table
 
Thanks Tom, Guillaume and Adrian.
My mistake in reversing the order of name and newname in the definition.
After the switch, it works.
 
But....I'm investigating another environment where the definition appears to have been correct and yet there is an error in select. Maybe I'll post again later, if needed.
 
Thanks.
 
A.A.
 
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, January 21, 2022 11:52 AM
To: Alanoly Andrews <alanolya@invera.com>
Subject: Re: Using a different column name in a foreign table
 
[Email External/Externe] Caution opening links or attachments/attention lors de l'ouverture de liens ou de pièces jointes.
 
Alanoly Andrews <alanolya@invera.com> writes:
> I see that the syntax for the creation of a foreign table allows you to use a column name in the FT that is different from the one in the base table. Such a "create foreign table" statement executes successfully and creates the FT. But when I query the FT, I get an error wrt to the column that had been renamed. See example below:
 
> create foreign table tab1_ft (
>     id int,
>     name char(10) options(column_name 'newname')) server xxxxxx
> options(schema_name 'public', table_name 'tab1');
 
> select * from tab1_ft;
 
> ERROR:  column "newname" does not exist
> HINT:  Perhaps you meant to reference the column "tab1.name".
> CONTEXT:  Remote SQL command: SELECT id, newname FROM public.tab1
 
> So, it seems that the when the remote SQL command is composed, the mapping of 'newname' to the 'name' in the base table does not take effect.
 
Huh?  The CONTEXT line shows what was issued to the remote server, and it's very obvious that we *are* asking for "newname", as indeed is also implied by the error issued by the remote.  I think you just didn't match the name correctly to the actual name on the remote.
 
                        regards, tom lane
 

This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.'. If the disclaimer can't be applied, attach the message to a new disclaimer message.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Does PostgreSQL do bind-peeking? Is `col like '%'` optimized-away by the planner?
Next
From: Ron
Date:
Subject: Re: Can commands be typed in to view geometry in PgAdmin?