Re: pg_stat_statements and "IN" conditions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_stat_statements and "IN" conditions
Date
Msg-id 655954.1646932319@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_stat_statements and "IN" conditions  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: pg_stat_statements and "IN" conditions  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_stat_statements and "IN" conditions  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
Dmitry Dolgov <9erthalion6@gmail.com> writes:
> New status: Waiting on Author

> This seems incorrect, as the only feedback I've got was "this is a bad
> idea", and no reaction on follow-up questions.

I changed the status because it seems to me there is no chance of
this being committed as-is.

1. I think an absolute prerequisite before we could even consider
changing the query jumbler rules this much is to do the work that was
put off when the jumbler was moved into core: that is, provide some
honest support for multiple query-ID generation methods being used at
the same time.  Even if you successfully make a case for
pg_stat_statements to act this way, other consumers of query IDs
aren't going to be happy with it.

2. You haven't made a case for it.  The original complaint was
about different lengths of IN lists not being treated as equivalent,
but this patch has decided to do I'm-not-even-sure-quite-what
about treating different Params as equivalent.  Plus you're trying
to invoke eval_const_expressions in the jumbler; that is absolutely
Not OK, for both safety and semantic reasons.

If you backed off to just treating ArrayExprs containing different
numbers of Consts as equivalent, maybe that'd be something we could
adopt without fixing point 1.  I don't think anything that fuzzes the
treatment of Params can get away with that, though.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: role self-revocation
Next
From: Andres Freund
Date:
Subject: Re: ltree_gist indexes broken after pg_upgrade from 12 to 13