Horton

Thread

Commits

  1. Add test case for EEOP_INNER_SYSVAR/EEOP_OUTER_SYSVAR executor opcodes.

  1. Test for trigger condition accessing system attributes

    Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> — 2018-05-10T08:58:11Z

    Hi,
I was investigating the cases when the system attributes are accessed
beyond the scans. After investigating set_plan_references(), I thought
that we never access system attributes beyond scans. This lead me to
assume that EEOP_INNER/OUTER_SYSVAR are not needed since we do not
access system attributes from an inner or outer slot. I removed the
defintions and code using those and ran regression. All the tests
passed. So, I was about to conclude that my assumption is correct. But
then looking at TriggerEnabled() I realised that we also (ab?)use
INNER/OUTER Vars for OLD/NEW tuples for trigger condition. If the WHEN
condition in CREATE TRIGGER command refers to a system attribute, we
will end up having INNER/OUTER var refering a system attribute, thus
exercising code for EEOP_INNER/OUTER_SYSVAR.

Here's patch containing a testcase exercizing that code using
EEOP_INNER/OUTER_SYSVAR.

0001 is the actual testcase and the output
0002 adds warnings where EEOP_OUTER/INNER_SYSVAR are used. This patch
is not for commit. It is only to make sure that the code gets
exercised by the test. When both the patches are applied, the test
shows those warnings.

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

  2. Re: Test for trigger condition accessing system attributes

    Heikki Linnakangas <hlinnaka@iki.fi> — 2018-07-10T13:17:50Z

    On 10/05/18 11:58, Ashutosh Bapat wrote:
> Hi,
> I was investigating the cases when the system attributes are accessed
> beyond the scans. After investigating set_plan_references(), I thought
> that we never access system attributes beyond scans. This lead me to
> assume that EEOP_INNER/OUTER_SYSVAR are not needed since we do not
> access system attributes from an inner or outer slot. I removed the
> defintions and code using those and ran regression. All the tests
> passed. So, I was about to conclude that my assumption is correct. But
> then looking at TriggerEnabled() I realised that we also (ab?)use
> INNER/OUTER Vars for OLD/NEW tuples for trigger condition. If the WHEN
> condition in CREATE TRIGGER command refers to a system attribute, we
> will end up having INNER/OUTER var refering a system attribute, thus
> exercising code for EEOP_INNER/OUTER_SYSVAR.
> 
> Here's patch containing a testcase exercizing that code using
> EEOP_INNER/OUTER_SYSVAR.

Pushed with some small changes. Thanks!

- Heikki

  3. Re: Test for trigger condition accessing system attributes

    Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> — 2018-07-10T13:19:30Z

    Thanks Heikki.

On Tue, Jul 10, 2018 at 6:47 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 10/05/18 11:58, Ashutosh Bapat wrote:
>>
>> Hi,
>> I was investigating the cases when the system attributes are accessed
>> beyond the scans. After investigating set_plan_references(), I thought
>> that we never access system attributes beyond scans. This lead me to
>> assume that EEOP_INNER/OUTER_SYSVAR are not needed since we do not
>> access system attributes from an inner or outer slot. I removed the
>> defintions and code using those and ran regression. All the tests
>> passed. So, I was about to conclude that my assumption is correct. But
>> then looking at TriggerEnabled() I realised that we also (ab?)use
>> INNER/OUTER Vars for OLD/NEW tuples for trigger condition. If the WHEN
>> condition in CREATE TRIGGER command refers to a system attribute, we
>> will end up having INNER/OUTER var refering a system attribute, thus
>> exercising code for EEOP_INNER/OUTER_SYSVAR.
>>
>> Here's patch containing a testcase exercizing that code using
>> EEOP_INNER/OUTER_SYSVAR.
>
>
> Pushed with some small changes. Thanks!
>
> - Heikki



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