Why you didn't reply this messages.
I was searching for this one several hours, thanks for M.Taghizadeh. I
think, if it place in contribution section of postgresql, it will avoid
wasting several hours for peoples like me that wants this one.
Does it have a bad implementaion?
Sorry I think it is a
Neil Conway <[EMAIL PROTECTED]> writes:
> - abandonded the falloc() idea. There really aren't that many
> short-lived allocations in the PL/PgSQL compiler, and using falloc()
> made it difficult to use List. Instead, make the CurrentMemoryContext
> the long-lived function context, and explicitly pf
Ameen - Etemady wrote:
> Why you didn't reply this messages.
>
> I was searching for this one several hours, thanks for M.Taghizadeh. I
> think, if it place in contribution section of postgresql, it will avoid
> wasting several hours for peoples like me that wants this one.
> Does it have a bad i
On Mon, 2005-02-07 at 12:55 -0500, Bruce Momjian wrote:
> Ameen - Etemady wrote:
> > Why you didn't reply this messages.
> >
> > I was searching for this one several hours, thanks for M.Taghizadeh. I
> > think, if it place in contribution section of postgresql, it will avoid
> > wasting several h
John Hansen <[EMAIL PROTECTED]> writes:
> It still does not answer his question, being if this is the way core
> will want to go?
I've been waiting to see other comments on it. I think this is
certainly not the long-term solution, but if enough people think
it is useful as a short-term hack then
On Mon, 2005-02-07 at 10:41 -0500, Tom Lane wrote:
> My recollection is that I was not nearly as worried about short-term
> pallocs in the plpgsql code itself, as about leakage in various main-
> backend routines that get called incidentally during parsing.
> backend/parser/ is quite cavalier about
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-02-07 at 10:41 -0500, Tom Lane wrote:
>> My recollection is that I was not nearly as worried about short-term
>> pallocs in the plpgsql code itself, as about leakage in various main-
>> backend routines that get called incidentally during parsi
On Mon, 2005-02-07 at 19:22 -0500, Tom Lane wrote:
> What might work is to run in the function context as the basic state,
> but switch to a short-term context when calling any main-backend code
> from pl_comp.c. I'm not sure how many such calls there are, but if it's
> not more than a dozen or tw
Neil Conway <[EMAIL PROTECTED]> writes:
> WRT calls to backend/parser, I can see LookupTypeName (pl_comp.c:1060),
> and parseTypeString (pl_comp.c:1627). Are these the only calls you had
> in mind, or am I missing some?
I haven't looked lately, but my recollection is that there are just a
few call
On Mon, 2005-02-07 at 21:25 -0500, Tom Lane wrote:
> I haven't looked lately, but my recollection is that there are just a
> few calls into the main backend from pl_comp.c. I'm not sure they are
> all to backend/parser though; check /catalog, etc as well.
Attached is a patch that implements this.
10 matches
Mail list logo
