From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Use $ parameters as replacement characters for pg_stat_statements |
Date: | 2017-03-14 11:27:39 |
Message-ID: | CA+TgmoYvgAFafHGMXEvkURjUPyygMnVBHggVOJkX+YzUcgbsJA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 13, 2017 at 6:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>>> I'd be in favor of a change
>>> that makes it easier to copy and paste a query, to run EXPLAIN and so
>>> on. Lukas probably realizes that there are no guarantees that the
>>> query text that appears in pg_stat_statements will even appear as
>>> normalized in all cases. The "sticky entry" stuff is intended to
>>> maximize the chances of that happening, but it's still generally quite
>>> possible (e.g. pg_stat_statements never swaps constants in a query
>>> like "SELECT 5, pg_stat_statements_reset()"). This means that we
>>> cannot really say that this buys us a machine-readable query text
>>> format, at least not without adding some fairly messy caveats.
>
>> Well, Lukas's original suggestion of using $n for a placeholder would
>> do that, unless there's already a $n with the same numerical value,
>> but Andres's proposal to use $-n or $:n would not.
>
> I don't much like the $-n or $:n proposals, as those are infringing on
> syntax space we might wish we had back someday. $:n also could cause
> confusion with psql variable substitution.
>
> I wonder if it would improve matters to use $n, but starting with the
> first number after the actual external Param symbols in the query.
That sounds pretty sensible, although I guess it's got the weakness
that you might get confused about which kind of $n you are looking at.
However, I'd be inclined to deem that a fairly minor weakness and go
with it: just because somebody could hypothetically get confused
doesn't mean that real people will.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-03-14 11:28:02 | Re: WIP: Faster Expression Processing v4 |
Previous Message | Kuntal Ghosh | 2017-03-14 11:22:24 | Re: exposing wait events for non-backends (was: Tracking wait event for latches) |