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

Re: PL/Perl embedding string common elements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: PL/Perl embedding string common elements
Date: 2005-08-21 01:18:49
Message-ID: 18624.1124587129@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> The attached patch moves the common elements of loose_embedding[]
> and strict_embedding[] to a macro so they can be maintained in
> one place.  As Tom Lane noticed, ::_plperl_to_pg_array was missing
> from strict_embedding[], which appears to be a bug.

Actually, it strikes me that this is working around a problem that
we shouldn't have in the first place: there should not be two different
embedding strings.  I hadn't noticed the use_strict GUC before, but
now that I see it, I think it's implemented in a completely awful
way.  Because the embedding string is only executed once per backend,
it's effectively impossible to change use_strict on the fly.  I think
we should be looking for another implementation of that feature, rather
than just cleaning up the minor breakage.  One would expect changes
in the variable to at least affect future function compilations in
the current backend, if not indeed recompiling already-compiled ones.

I'm not much of a Perl guru, but could we make this happen by having
four functions instead of two?  (mksafefunc, mksafestrictfunc, etc)
I'm not too clear on what the scope of effects of 'use strict' is.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Andrew DunstanDate: 2005-08-21 02:18:21
Subject: Re: PL/Perl embedding string common elements
Previous:From: Tom LaneDate: 2005-08-20 23:48:49
Subject: Re: prevent encoding conversion recursive error

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