Re: Use %u to print user mapping's umid and userid
От | Etsuro Fujita |
---|---|
Тема | Re: Use %u to print user mapping's umid and userid |
Дата | |
Msg-id | 56E66F61.3070201@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Use %u to print user mapping's umid and userid (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: Use %u to print user mapping's umid and userid
Re: Use %u to print user mapping's umid and userid |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: