| From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Patch to fix search_path defencies with pg_bench |
| Date: | 2009-05-06 19:29:49 |
| Message-ID: | 1241638189.4278.67.camel@jd-laptop.pragmaticzealot.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2009-05-06 at 15:13 -0400, Alvaro Herrera wrote:
> Dickson S. Guedes wrote:
> > 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.
>
> I think it would be better that the schema is specified on the command
> line.
I could see that as an option but applications that use a role should
adhere to the rules the DBA sets forth for that role. In this particular
case I explicitly said that role bench01 was to connect to the database
bench and that his search path was bench01 (thus all tables would be
created under the schema bench01). Public should never come into play in
that scenario.
Sincerely,
Joshua D. Drake
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zdenek Kotala | 2009-05-06 19:53:13 | Re: lazy vacuum blocks analyze |
| Previous Message | Tom Lane | 2009-05-06 19:18:05 | Re: Patch to fix search_path defencies with pg_bench |