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
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
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,
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
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
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
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
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
On 2016/05/11 18:03, Ashutosh Bapat wrote:
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
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
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
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
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
> 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
>> > wrote:
>
>> /*
>> * Build the
On 2016/03/14 17:56, Ashutosh Bapat wrote:
On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
> wrote:
/*
* Build the fdw_private list that will be available to the
executor.
* Items in the list must
> -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.
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:
/*
*
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:
Here is a patch to use %u not %d to print umid and userid.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/connection.c
--- b/contrib/postgres_fdw/connection.c
***
*** 159,165 GetConnection(UserMapping *user, bool will_prep_stmt)
entry->have_error = false;
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
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
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
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
25 matches
Mail list logo