Robert Haas <robertmh...@gmail.com> writes: > Yeah. The API contract for an expanded object took me quite a while > to puzzle out, but it seems to be this: if somebody hands you an R/W > pointer to an expanded object, you're entitled to assume that you can > "take over" that object and mutate it however you like. But the > object might be in some other memory context, so you have to move it > into your own memory context.
Only if you intend to keep it --- for example, a function that is mutating and returning an object isn't required to move it somewhere else, if the input is R/W, and I think it generally shouldn't. In the context here, I'd think it is the responsibility of nodeAgg.c not individual datatype functions to make sure that expanded objects live where it wants them to. > Well, that's pretty odd. I guess the plan change must be a result of > switching the transition type from internal to text, although I'm not > immediately certain why that would make a difference. I'm pretty sure there's something in the planner that special-cases its estimate of space consumed by hashtable entries when the data type is "internal". You'd be wanting to fool with that estimate anyway for something like this ... regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers