On Fri, Nov 5, 2010 at 2:56 PM, Tom Lane wrote:
> It's not cheap :-( ... but it's *necessary*. There's no other way to
> get sane behavior.
>
> If the cost annoys you, you should put some effort into making subxact
> start/stop cheaper overall, rather than trying to avoid having one here.
I woul
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> PS: I'm wondering if there's any noticable slowdown from always starting
> a subxact before doing SPI. Plperl users seemed not to notice, so I
> guess I shouldn't worry.
It's not cheap :-( ... but it's *necessary*. There's no other way to
get sane behav
Excerpts from Jan Urbański's message of vie nov 05 04:19:07 -0300 2010:
> PS: I'm wondering if there's any noticable slowdown from always starting
> a subxact before doing SPI. Plperl users seemed not to notice, so I
> guess I shouldn't worry.
I think it's more "plperl users have to put up with i
On 04/11/10 20:43, Hannu Krosing wrote:
> On Thu, 2010-11-04 at 11:07 -0600, Alex Hunsaker wrote:
>> On Thu, Nov 4, 2010 at 03:54, Hannu Krosing wrote:
> try:
> plpy.execute("insert into foo values(1)")
> except plpy.UniqueViolation, e:
> plpy.notice("Ooops, you got yoursel
On Thu, Nov 4, 2010 at 14:29, Alex Hunsaker wrote:
> On Thu, Nov 4, 2010 at 13:43, Hannu Krosing wrote:
>> So your plan was to have some savepoint before each execute ?
>>
>> How would one rollback the latest transaction ?
>
> It is always rolled back. Its how plperl works today:
> create or rep
On Thu, Nov 4, 2010 at 13:43, Hannu Krosing wrote:
> So your plan was to have some savepoint before each execute ?
>
> How would one rollback the latest transaction ?
It is always rolled back. Its how plperl works today:
create or replace function foo() returns int as $$
eval {
spi_exec_quer
On Nov 4, 2010, at 4:20 AM, Peter Eisentraut wrote:
> On ons, 2010-11-03 at 14:15 -0700, David E. Wheeler wrote:
>> /me wants a global $dbh that mimics the DBI interface but just uses
>> SPI under the hood. Not volunteering, either…
>
> Already exists: DBD::PgSPI. Probably needs lots of updating
On Thu, 2010-11-04 at 11:07 -0600, Alex Hunsaker wrote:
> On Thu, Nov 4, 2010 at 03:54, Hannu Krosing wrote:
> >> > try:
> >> > plpy.execute("insert into foo values(1)")
> >> > except plpy.UniqueViolation, e:
> >> > plpy.notice("Ooops, you got yourself a SQLSTATE %d", e.sqlstate)
> >>
> >>
On Thu, Nov 4, 2010 at 03:54, Hannu Krosing wrote:
>> > try:
>> > plpy.execute("insert into foo values(1)")
>> > except plpy.UniqueViolation, e:
>> > plpy.notice("Ooops, you got yourself a SQLSTATE %d", e.sqlstate)
>>
>> Are you sure that having each try/except use a subtransaction is the
Hannu Krosing writes:
> Are you sure that having each try/except use a subtransaction is the
> right way to do it ?
Actually it is not: what you have to do is use a subtransaction in the
plpy.execute() operation, so that if the called SQL operation fails, you
can clean it up and then report the e
On ons, 2010-11-03 at 14:15 -0700, David E. Wheeler wrote:
> /me wants a global $dbh that mimics the DBI interface but just uses
> SPI under the hood. Not volunteering, either…
Already exists: DBD::PgSPI. Probably needs lots of updating through.
--
Sent via pgsql-hackers mailing list (pgsql-ha
On Thu, 2010-11-04 at 11:46 +0200, Hannu Krosing wrote:
> On Wed, 2010-11-03 at 21:43 +0100, Jan Urbański wrote:
> > The validator is ready, once I'm done with the hash tables I'll try to
> > fix up the error checking (get rid of the global error state) and
> > finally do what started it all, that
On Wed, 2010-11-03 at 21:43 +0100, Jan Urbański wrote:
> The validator is ready, once I'm done with the hash tables I'll try to
> fix up the error checking (get rid of the global error state) and
> finally do what started it all, that is make plpythonu use
> subtransactions for SPI and be able to d
On Nov 3, 2010, at 2:06 PM, Alex Hunsaker wrote:
>> try:
>>plpy.execute("insert into foo values(1)")
>> except plpy.UniqueViolation, e:
>>plpy.notice("Ooops, you got yourself a SQLSTATE %d", e.sqlstate)
>
> Ouuu .
>
> [ now that eval { }, thanks to Tim Bunce, works with plperl it should
On Wed, Nov 3, 2010 at 14:43, Jan Urbański wrote:
> By the way, I'm leaning in the direction of not using a Python
> dictionary for the cache, but a standard Postgres HTAB instead. It's
> more like other pls this way, and you can get rid of PyCObjects (which
> are deprecated BTW) and messing aroun
On 03/11/10 20:57, Alex Hunsaker wrote:
> On Wed, Nov 3, 2010 at 10:28, Tom Lane wrote:
>> OK, applied.
>
> Thanks!
>
>> I notice that plpython is also using the trigger relation's OID, but I
>> don't know that language well enough to tell whether it really needs to.
>
> This thread was started
On Wed, Nov 3, 2010 at 10:28, Tom Lane wrote:
> OK, applied.
Thanks!
> I notice that plpython is also using the trigger relation's OID, but I
> don't know that language well enough to tell whether it really needs to.
This thread was started by someone working a plpython a validator, I
figured t
Alex Hunsaker writes:
> On Mon, Nov 1, 2010 at 16:59, Tom Lane wrote:
>> Surely, removing the internal name's dependency on the istrigger flag is
>> wrong. Â If you're going to maintain separate hash entries at the pltcl
>> level, why would you want to risk collisions underneath that?
> Good cat
On Mon, Nov 1, 2010 at 16:59, Tom Lane wrote:
> Alex Hunsaker writes:
>> Speaking of which, pltcl stores the trigger reloid instead of a flag
>> (it also uses tg_reloid in the internal proname). It seems a tad
>> excessive to have one function *per* trigger table.
>
> Surely, removing the intern
Alex Hunsaker writes:
> Speaking of which, pltcl stores the trigger reloid instead of a flag
> (it also uses tg_reloid in the internal proname). It seems a tad
> excessive to have one function *per* trigger table. I looked through
> the history to see if there was some reason, it goes all the wa
On Mon, Nov 1, 2010 at 15:24, Alex Hunsaker wrote:
houldn't cache any of the setup but just redo it all every time.
>
> Huh? I might try and argue that if the new test was more complex than
> 2 compares :P. In-fact the way it stands now we uselessly grab the
> functions pg_proc entry in the comm
On Mon, Nov 1, 2010 at 09:28, Tom Lane wrote:
> I think the crash is dependent on the fact that the function is created
> and called in the same session. That means the validator gets called on
> it first, and the validator not unreasonably assumes istrigger = true,
> and then it calls compile_pl
On 11/01/2010 11:28 AM, Tom Lane wrote:
The fundamental issue here is that the contents of plperl_proc_desc
structs are different between the trigger and non-trigger cases.
Unless you're prepared to make them the same, and guarantee that they
always will be the same in future, I think that in
Andrew Dunstan writes:
> On 10/31/2010 04:40 PM, Alex Hunsaker wrote:
>> which happens because prodesc->result_in_func.fn_addr (flinfo) is
>> NULL. That happens because when we are a trigger we don't setup
>> input/output conversion. And with the change we get the same
>> proc_desc for triggers
On Sun, Oct 31, 2010 at 15:17, Andrew Dunstan wrote:
> On 10/31/2010 04:40 PM, Alex Hunsaker wrote:
>> And with the change we get the same
>> proc_desc for triggers and non triggers, so if the trigger function
>> gets called first, any call to the direct function will use the same
>> proc_desc wit
On 10/31/2010 04:40 PM, Alex Hunsaker wrote:
On Sun, Oct 31, 2010 at 12:00, Andrew Dunstan wrote:
On 10/31/2010 11:44 AM, Tom Lane wrote:
Good catch, patch reverted (and regression test added).
Well, I guess that answers the question of why we needed it, which nobody
could answer before. I'
On Sun, Oct 31, 2010 at 12:00, Andrew Dunstan wrote:
> On 10/31/2010 11:44 AM, Tom Lane wrote:
>> Good catch, patch reverted (and regression test added).
>
> Well, I guess that answers the question of why we needed it, which nobody
> could answer before. I'm not sure I exactly understand what's go
On 10/31/2010 11:44 AM, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Seems that this circumverts some output conversion error checking, since
adding the attached to the regression suite results in a segfault during
the plperl installcheck.
Reverting 2d01ec0708d571eef926f3f5795aa73
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> Seems that this circumverts some output conversion error checking, since
> adding the attached to the regression suite results in a segfault during
> the plperl installcheck.
> Reverting 2d01ec0708d571eef926f3f5795aa73759df5d9a fixes it.
Good catch, pat
On 25/10/10 03:59, Andrew Dunstan wrote:
>
>
> On 10/24/2010 09:34 PM, Tom Lane wrote:
>>
>>> For both trigger and non-trigger functions, we compile this ahead of the
>>> user-set function code:
>>> our $_TD; local $_TD=shift;
>>> Non-trigger functions get passed "undef" to correspond to thi
On 10/24/2010 09:34 PM, Tom Lane wrote:
For both trigger and non-trigger functions, we compile this ahead of the
user-set function code:
our $_TD; local $_TD=shift;
Non-trigger functions get passed "undef" to correspond to this invisible
argument, while trigger functions get passed the h
Andrew Dunstan writes:
> On 10/24/2010 07:50 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Why do we need the is_trigger flag at all for the plperl hash key? At
>>> first glance it strikes me as unnecessary.
>> We might not. Does the presence or absence of the $_TD hash reference
>> have an
On 10/24/2010 07:50 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 10/24/2010 06:44 PM, Tom Lane wrote:
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
Andrew Dunstan writes:
> On 10/24/2010 06:44 PM, Tom Lane wrote:
>> 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.
We might not.
On 10/24/2010 06:44 PM, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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
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?
I'm trying to write a validator f
37 matches
Mail list logo
