| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> | 
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Use %u to print user mapping's umid and userid | 
| Date: | 2016-03-14 07:59:29 | 
| Message-ID: | 56E66F61.3070201@lab.ntt.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Hi,
On 2016/02/09 14:09, Ashutosh Bapat wrote:
> Sorry, I was wrong. For public user mapping userid is 0 (InvalidOid),
> which is returned as is in UserMapping object. I confused InvalidOid
> with -1.
I think the following umid handling in postgresGetForeignPlan has the 
same issue:
     /*
      * Build the fdw_private list that will be available to the executor.
      * Items in the list must match order in enum FdwScanPrivateIndex.
      */
     fdw_private = list_make4(makeString(sql.data),
                              retrieved_attrs,
                              makeInteger(fpinfo->fetch_size),
                              makeInteger(foreignrel->umid));
I don't think it's correct to use makeInteger for the foreignrel's umid.
You store the umid in the fdw_private list here and extract it from the 
list in postgresBeginForeignScan, to get the user mapping.  But we 
really need that?  We have a validated plan when getting called from 
postgresBeginForeignScan, so if foreign join, we can simply pick any of 
the plan's fs_relids and use it to identify which user to do the remote 
access as, in the same way as for foreign tables.
Attached is a patch for that.
Best regards,
Etsuro Fujita
| Attachment | Content-Type | Size | 
|---|---|---|
| postgres-fdw-umid.patch | application/x-patch | 4.0 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2016-03-14 08:31:18 | Re: Obsolete comment in postgres_fdw.c | 
| Previous Message | Torsten Zühlsdorff | 2016-03-14 07:47:37 | Re: [HACKERS] How can we expand PostgreSQL ecosystem? |