Etsuro Fujita writes:
> On 2016/05/13 3:53, Tom Lane wrote:
>> Robert Haas writes:
>>> Regardless of what approach we take, I disagree that this needs to be
>>> fixed in 9.6.
>> Agreed. This is only a cosmetic issue, and it's only going to be visible
>> to a very small group of people, so we ca
On 2016/05/13 3:53, Tom Lane wrote:
Robert Haas writes:
Regardless of what approach we take, I disagree that this needs to be
fixed in 9.6.
Agreed. This is only a cosmetic issue, and it's only going to be visible
to a very small group of people, so we can leave it alone until 9.7.
Agreed.
Robert Haas writes:
> My suggestion is that we switch from using a List to marshal the data
> to using an ExtensibleNode. An advantage of that is that we'd have
> some in-core test coverage for the ExtensibleNode stuff. In theory it
> ought to be simpler and less messy, too, but I guess we'll fi
On Thu, May 12, 2016 at 2:29 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> My suggestion is that we switch from using a List to marshal the data
>> to using an ExtensibleNode. An advantage of that is that we'd have
>> some in-core test coverage for the ExtensibleNode stuff. In theory it
>> o
Robert Haas wrote:
> My suggestion is that we switch from using a List to marshal the data
> to using an ExtensibleNode. An advantage of that is that we'd have
> some in-core test coverage for the ExtensibleNode stuff. In theory it
> ought to be simpler and less messy, too, but I guess we'll fin
On Thu, May 12, 2016 at 12:18 AM, Etsuro Fujita
wrote:
> I think if scanning a foreign join, the user mapping is still valid at
> execution, and that is ensured by RevalidateChachedQuery, IIUC.
Yes, we added special machinery for that, along the lines of what is
also done for RLS.
But I have to
On 2016/05/12 13:02, Tom Lane wrote:
Etsuro Fujita writes:
On 2016/05/11 18:03, Ashutosh Bapat wrote:
A call to GetForeignTable would incur a catalog lookup which means a
catalog table/index scan if corresponding entry is not in the cache.
This is followed by GetUserMapping() which is another
Etsuro Fujita writes:
> On 2016/05/11 18:03, Ashutosh Bapat wrote:
>> A call to GetForeignTable would incur a catalog lookup which means a
>> catalog table/index scan if corresponding entry is not in the cache.
>> This is followed by GetUserMapping() which is another catalog access.
>> That's boun
On 2016/05/11 18:03, Ashutosh Bapat wrote:
On Wed, May 11, 2016 at 1:34 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/05/11 16:49, Ashutosh Bapat wrote:
The patch is calculating user mapping when it's readily available
through RelOptInfo::fdw_privat
On Wed, May 11, 2016 at 1:34 PM, Etsuro Fujita
wrote:
> On 2016/05/11 16:49, Ashutosh Bapat wrote:
>
>> The patch is calculating user mapping when it's readily available
>> through RelOptInfo::fdw_private. That incurs a catalog lookup
>> unnecessarily. Instead, can we add new function makeOid, oi
On 2016/05/11 16:49, Ashutosh Bapat wrote:
The patch is calculating user mapping when it's readily available
through RelOptInfo::fdw_private. That incurs a catalog lookup
unnecessarily. Instead, can we add new function makeOid, oidVal on the
lines of makeInteger and intVal to store and retrieve a
On Wed, May 11, 2016 at 1:10 PM, Etsuro Fujita
wrote:
> On 2016/05/10 16:56, Etsuro Fujita wrote:
>
>> Here is a patch to fix this.
>>
>
> I found that the previous patch handles the ForeignScan's fs_relids
> Bitmapset destructively. Also, I noticed that I removed some existing
> comments inadve
On 2016/05/10 16:56, Etsuro Fujita wrote:
Here is a patch to fix this.
I found that the previous patch handles the ForeignScan's fs_relids
Bitmapset destructively. Also, I noticed that I removed some existing
comments inadvertently. So, I'm attaching the updated patch to fix
those things.
On 2016/05/02 22:06, Robert Haas wrote:
On Thu, Apr 28, 2016 at 7:59 AM, Etsuro Fujita
wrote:
On 2016/03/14 17:56, Ashutosh Bapat wrote:
On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
/*
* Build the fdw_private list that will be
On Thu, Apr 28, 2016 at 7:59 AM, Etsuro Fujita
wrote:
> On 2016/03/14 17:56, Ashutosh Bapat wrote:
>> On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>
>> /*
>> * Build the fdw_private list that will be available to the
>> execut
On 2016/03/14 17:56, Ashutosh Bapat wrote:
On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
/*
* Build the fdw_private list that will be available to the
executor.
* Items in the list must match order in enum FdwScanPri
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
> Sent: Monday, March 14, 2016 4:59 PM
> To: Ashutosh Bapat; Tom Lane
> Cc: pgsql-hackers
> Subject: Re: [HACKERS] Use %u to prin
On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
wrote:
> 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 um
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:
/*
*
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.
Sorry for the confusion.
On Tue, Feb 9, 2016 at 10:21 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Sorry to come to this late.
> > The userid b
Ashutosh Bapat writes:
> Sorry to come to this late.
> The userid being printed is from UserMapping. The new API
> GetUserMappingById() allows an FDW to get user mapping by its OID. This API
> is intended to be used by FDWs to fetch the user mapping inferred by the
> core for given join between fo
On Tue, Feb 9, 2016 at 1:22 PM, Ashutosh Bapat
wrote:
> The userid being printed is from UserMapping. The new API
> GetUserMappingById() allows an FDW to get user mapping by its OID. This API
> is intended to be used by FDWs to fetch the user mapping inferred by the
> core for given join between f
Sorry to come to this late.
The userid being printed is from UserMapping. The new API
GetUserMappingById() allows an FDW to get user mapping by its OID. This API
is intended to be used by FDWs to fetch the user mapping inferred by the
core for given join between foreign relations. In such user map
Etsuro Fujita writes:
> Here is a patch to use %u not %d to print umid and userid.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hac
24 matches
Mail list logo
