Re: [Postgres-xc-developers] Patch ready for review: online data redistribution

On Wed, Jul 11, 2012 at 3:03 PM, Michael Paquier
<mic...@gm...>wrote:

>
>
> Ok, understood. In this case, I will recommend two things
>> 1. Whether an internal COPY generation can use CopyState itself?
>>
> Not a good idea... Another idea I have:
> Only RemoteCopy_BuildStatement is using RemoteCopyOptions. So let's
> eliminate it and RemoteCopy_BuildStatement being called with all the
> arguments it has in. It makes the function a bit longer, but avoids to have
> to copy all the elements of CopyState into an intermediate structure. What
> would be tricky to maintain btw.
> I recall that CreateProcedure in postgres does smth similar.
>
>
That will make the function signature too long and prone to errors if
arguments get jumbled up in the call (there are 9 members btw). Why can't
we use CopyState structure with only the options initialised?


> 2. If this structure is essential, rename the member variables with some
>> prefix like "rco_", to distinguish those from their CopyState counterparts.
>> This helps a lot when one wants to navigate code looking for all usages of
>> a particular member using say cscope or tags. Unfortunately PostgreSQL
>> doesn't use this idea and hence very common names like larg are used in
>> many structures and makes it difficult to find out say all usages of larg
>> in say SetOperationStmt.
>>
> Not that much essential if we use my idea above
> --
> Michael Paquier
> http://michael.otacoo.com
>



-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company