| From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: PATCH: CITEXT 2.0 |
| Date: | 2008-07-05 05:54:45 |
| Message-ID: | 3816229E-1D37-48A6-8584-280139AA9171@kineticode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Jul 2, 2008, at 22:14, Tom Lane wrote:
> The "leak" is irrelevant for larger/smaller. The only place where
> it's
> actually useful to do PG_FREE_IF_COPY is in a btree or hash index
> support function. In other cases you can assume that you're being
> called in a memory context that's too short-lived for it to matter.
Stupid question: for the btree index support function, is that *only*
the function referenced in the OPERATOR CLASS, or does it also apply
to functions that implement the operators in that class? IOW, do I
need to worry about memory leaks in citext_eq, citext_ne, citext_gt,
etc., or only in citext_cmp()?
Thanks,
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2008-07-05 06:06:36 | Re: PATCH: CITEXT 2.0 |
| Previous Message | David E. Wheeler | 2008-07-05 05:39:54 | Re: PATCH: CITEXT 2.0 |