Skip site navigation (1) Skip section navigation (2)

Re: why does plperl cache functions using just a bool for is_trigger

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Urbański <wulczer(at)wulczer(dot)org>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: why does plperl cache functions using just a bool for is_trigger
Date: 2010-10-24 23:05:29
Message-ID: 4CC4BBB9.4050702@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

On 10/24/2010 06:44 PM, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?=<wulczer(at)wulczer(dot)org>  writes:
>> I see that plperl uses a triple of (function oid, is_trigger flag, user
>> id) as a hash key for caching compiled functions. OTOH pltcl and plpgsql
>> both use (oid, trigger relation oid, user id). Is there any reason why
>> just using a bool as plperl does would be wrong?
> plpgsql needs to consider the trigger relation OID because datatypes of
> the trigger relation's columns will make their way into cached plans
> for the function.  The same function, if applied as a trigger on two
> different rels, could therefore have different cached plans so it needs
> two separate cache entries.
>
> In PLs where this kind of dependency isn't possible, there's no need for
> separate function cache entries.
>
> I'm not certain that plperl is actually correct to do it that way,
> but that's the basic idea.

Why do we need the is_trigger flag at all for the plperl hash key? At 
first glance it strikes me as unnecessary.

cheers

andrew

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-10-24 23:11:51
Subject: Re: ask for review of MERGE
Previous:From: Tom LaneDate: 2010-10-24 22:59:34
Subject: Re: Range Types, discrete and/or continuous

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group