postgres-xc-developers Mailing List for Postgres-XC

Just a quick question about contributing fixes. I've had to make some minor changes to get XC compiled on Solaris x64.
What format would you like to see for the changes? Most are very minor, such as removing return statements inside void functions (which the Solaris compiler flags as incorrect since you can't return from a void function).
Matt

I agree on Ashutosh's comment but this may need another analysis and
cleanup of the current code blocking distribution column updates too.
Could be  time consuming so I think Amit's approach is okay now (we need a
cleanup anyway later).

Regards;

----------
Koichi Suzuki


2013/6/20 Amit Khandekar <ami...@en...>

>
>
> On 20 June 2013 11:25, Ashutosh Bapat <ash...@en...>wrote:
>
>> HI Amit,
>> Can we move this check deep into heap_update or something? That way we
>> can cover all the ways partition column can be updated.
>>
>
> That needs some amount of analysis on to what extent these checks in
> heap_update() impacts performance. Currently we disallow updating partition
> columns in SQLs, so a user would expect restricting such updates everywhere
> else, and trigger is one area where these updates are silently ignored.
>
>
>>
>> On Thu, Jun 20, 2013 at 10:25 AM, Amit Khandekar <
>> ami...@en...> wrote:
>>
>>> Currently there is no check if the trigger function has modified the
>>> partition column for UPDATE. Attached patch does the verification in
>>> ExecBRUpdateTriggers(). INSERT does not require it, because it is a new row
>>> being inserted, and if the trigger function modifies the column values, the
>>> INSERT gets executed on the datanode corresponding to the final
>>> distribution value of the row.
>>>
>>> A user can still make the trigger function immutable and if this trigger
>>> runs on datanode, it will be able to do partition column updates, but then
>>> it can be done by any other function by just making it immutable and doing
>>> partition column updates via an SQL statement; it's the user's
>>> reponsibility to mark functions immutable carefully.
>>>
>>> Added  testcases in xc_triggers.sql.
>>>
>>> -Amit
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Postgres Database Company
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>

On 20 June 2013 11:25, Ashutosh Bapat <ash...@en...>wrote:

> HI Amit,
> Can we move this check deep into heap_update or something? That way we can
> cover all the ways partition column can be updated.
>

That needs some amount of analysis on to what extent these checks in
heap_update() impacts performance. Currently we disallow updating partition
columns in SQLs, so a user would expect restricting such updates everywhere
else, and trigger is one area where these updates are silently ignored.


>
> On Thu, Jun 20, 2013 at 10:25 AM, Amit Khandekar <
> ami...@en...> wrote:
>
>> Currently there is no check if the trigger function has modified the
>> partition column for UPDATE. Attached patch does the verification in
>> ExecBRUpdateTriggers(). INSERT does not require it, because it is a new row
>> being inserted, and if the trigger function modifies the column values, the
>> INSERT gets executed on the datanode corresponding to the final
>> distribution value of the row.
>>
>> A user can still make the trigger function immutable and if this trigger
>> runs on datanode, it will be able to do partition column updates, but then
>> it can be done by any other function by just making it immutable and doing
>> partition column updates via an SQL statement; it's the user's
>> reponsibility to mark functions immutable carefully.
>>
>> Added  testcases in xc_triggers.sql.
>>
>> -Amit
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Postgres Database Company
>

HI Amit,
Can we move this check deep into heap_update or something? That way we can
cover all the ways partition column can be updated.


On Thu, Jun 20, 2013 at 10:25 AM, Amit Khandekar <
ami...@en...> wrote:

> Currently there is no check if the trigger function has modified the
> partition column for UPDATE. Attached patch does the verification in
> ExecBRUpdateTriggers(). INSERT does not require it, because it is a new row
> being inserted, and if the trigger function modifies the column values, the
> INSERT gets executed on the datanode corresponding to the final
> distribution value of the row.
>
> A user can still make the trigger function immutable and if this trigger
> runs on datanode, it will be able to do partition column updates, but then
> it can be done by any other function by just making it immutable and doing
> partition column updates via an SQL statement; it's the user's
> reponsibility to mark functions immutable carefully.
>
> Added  testcases in xc_triggers.sql.
>
> -Amit
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


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