Re: BUG: pg_stat_statements query normalization issues with combined queries

I wrote:
> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>> One point bothered me a bit when looking at the initial code, that your
>> refactoring has not changed: the location is about a string which is not
>> accessible from the node, so that the string must be kept elsewhere and
>> passed as a second argument here and there. ISTM that it would make some
>> sense to have the initial string directly available from RawStmt, Query
>> and PlannedStmt.

> Yeah, perhaps, but that would be something to tackle as a separate round
> of changes I think.

I remembered one reason why we haven't done this: it's unclear how we'd
handle copying if we do it. If, say, Query contains a "char *" pointer
then you'd expect copyObject() to pstrdup that string, but we really don't
want that to happen in scenarios where a single source string generated a
large number of Query trees. That's not an academic concern, we've gotten
real field bug reports when we broke it --- cf commit 1591fcbec. We'd
need to work out a way of managing multiple Queries carrying references
to the same source string, and it's not clear how to do that reasonably.
So for now, it remains the path of least resistance for Portals and
CachedPlans to contain a list of Query or PlannedStmt objects and a
separate source string.

regards, tom lane