Re: Patch to fix search_path defencies with pg_bench
От | Robert Haas |
---|---|
Тема | Re: Patch to fix search_path defencies with pg_bench |
Дата | |
Msg-id | 603c8f070905070814w4ee5282j355d5e497e3a18c1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch to fix search_path defencies with pg_bench (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Patch to fix search_path defencies with pg_bench
Re: Patch to fix search_path defencies with pg_bench |
Список | pgsql-hackers |
On Thu, May 7, 2009 at 10:12 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > On Wed, 2009-05-06 at 15:18 -0400, Tom Lane wrote: >> "Dickson S. Guedes" <listas@guedesoft.net> writes: >> > Em Qua, 2009-05-06 s 09:37 -0400, Tom Lane escreveu: >> >> Seems like the right policy for that is "run pgbench in its own >> >> database". >> >> > A text warning about this could be shown at start of pgbench if the >> > target database isn't named "pgbench", for examplo, or just some text >> > could be added to the docs. >> >> There already is a prominent warning in the pgbench docs: >> >> Caution >> >> pgbench -i creates four tables accounts, branches, history, and >> tellers, destroying any existing tables of these names. Be very >> careful to use another database if you have tables having these >> names! > > Holy Handgrenade, what a huge footgun! It doesn't even have a > conceivable upside. > > The table names "accounts" and "history" are fairly common and a caution > isn't a sufficient safeguard on production data. We know the manual > rarely gets read *after* a problem, let alone beforehand. > > We should check they are the correct tables before we just drop them. > Perhaps check for the comment "Tables for pgbench application. Not > production data" on the tables, which would be nice to add anyway. I bet it would be just as good and a lot simpler to do what someone suggested upthread, namely s/^/pgbench_/ ...Robert
В списке pgsql-hackers по дате отправления: