Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements |
Дата | |
Msg-id | CA+TgmoYvgAFafHGMXEvkURjUPyygMnVBHggVOJkX+YzUcgbsJA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements
|
Список | pgsql-hackers |
On Mon, Mar 13, 2017 at 6:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan <pg@bowt.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
В списке pgsql-hackers по дате отправления: