Re: Pre-alloc ListCell's optimization
Greg Stark <gsstark@mit.edu>
From: Greg Stark <gsstark@mit.edu>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-05-27T03:58:58Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Replace the parser's namespace tree (which formerly had the same
- a4996a895399 8.1.0 cited
-
Turns out that my recent elimination of the 'redundant' flatten_andors()
- 56c88772911b 8.1.0 cited
On Thu, May 26, 2011 at 8:52 PM, Stephen Frost <sfrost@snowman.net> wrote: > list_concat() does explicitly say that cells will > be shared afterwards and that you can't pfree() either list (note that > there's actually a couple cases currently that I discovered which were > also addressed in the original patch where I commented out those > pfree()'s). So in traditional list it would splice the second argument onto the end of the first list. This has a few effects that it sounds like you haven't preserved. For example if I insert an element anywhere in list2 -- including in the first few elements -- it's also inserted into list1. I'm not really sure we care about these semantics with our lists though. It's not like they're supposed to be a full-featured lisp emulator and it's not like the C code pulls any particularly clever tricks with lists. I suspect we may have already broken these semantics long ago but I haven't looked to see if that's the case. -- greg