From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: POC: converting Lists into arrays |
Date: | 2019-02-25 23:41:17 |
Message-ID: | 9751.1551138077@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> 1. This still involves at least two palloc's for every nonempty List,
>>> because I kept the header and the data array separate. Perhaps it's
>>> worth allocating those in one palloc.
>> Hm, I think if we force external code to audit their code, we better
>> also do this. This is a significant number of allocations, and I don't
>> think it'd be good to spread this out over two releases.
> If we choose to do it, I'd agree with doing both in the same major release
> cycle, so that extensions see just one breakage. But I think it'd still
> best be developed as a follow-on patch.
By the by ... this idea actively breaks the mechanism I'd proposed for
preserving foreach's behavior of evaluating the List reference only once.
If we save a hidden copy of whatever the user says the List reference
is, and then he assigns a new value to it mid-loop, we're screwed if
the list header can move.
Now do you see why I'm a bit afraid of this? Perhaps it's worth doing,
but it's going to introduce a whole new set of code breakages that are
going to be just as hard to audit for as anything else discussed in
this thread. (Example: outer function creates a nonempty list, and
passes it down to some child function that appends to the list, and
there's no provision for returning the possibly-modified list header
pointer back up.) I'm not really convinced that saving one more palloc
per List is worth it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-26 00:09:11 | Re: Allowing extensions to supply operator-/function-specific info |
Previous Message | Paul Ramsey | 2019-02-25 23:39:49 | Re: Allowing extensions to supply operator-/function-specific info |