Re: Use %u to print user mapping's umid and userid

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-hackers by date

  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?