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

Re: memory context for tuplesort return values

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: memory context for tuplesort return values
Date: 2006-02-23 22:13:48
Message-ID: 20060223221348.GE8798@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Crazy ideas: add a #warning or #error to the header file unless there is
> > some special symbol previously defined, something like
> > #define I_UNDERSTAND_MEM_ALLOC_IN_TUPLETABLESLOT
> > which means the developer did update his code.
> 
> Well, if we wanted to go that far, the simple solution is to rename
> tuplesort_gettuple to something else.  Guaranteed code breakage then.
> However, I think this is overkill for a problem that only *might*
> bite people.  I kinda doubt that people are using TupleTableSlots in
> add-on code, because the design of the executor makes it hard for
> anything except plan nodes to obtain slots.

Yeah, you may be right.  I guess I was worried because the Mammoth
Replicator code uses TupleTableSlots here and there and I was assuming
that other developers may have similar code.  However, Replicator is
fairly involved stuff, and I don't see that TupleTableSlots would have
much use outside something that tied to the internals.  And of course,
every major Postgres release is major surgery for Replicator as well, so
nothing new here :-(

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-hackers by date

Next:From: Jan CruzDate: 2006-02-23 23:39:58
Subject: suggestion
Previous:From: Tom LaneDate: 2006-02-23 22:01:41
Subject: Re: memory context for tuplesort return values

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