Re: Patch to fix search_path defencies with pg_bench

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>, Greg Smith <gsmith(at)gregsmith(dot)com>, jd(at)commandprompt(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch to fix search_path defencies with pg_bench
Date: 2009-05-07 16:46:35
Message-ID: 20090507164635.GF3305@yugib.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas <robertmhaas(at)gmail(dot)com> [090507 11:15]:

> I bet it would be just as good and a lot simpler to do what someone
> suggested upthread, namely s/^/pgbench_/

That has the "legacy compatibility" problem...

But seeing as "legacy" has a:
SET search_path TO public;

And uses plain <table> in it's queries/creates/drops, couldn't we just
make "new" pgbench refer to tables as <schema>.<table> where <schema> is
"public"? If we leave "schema" as public, and leave in the search_path,
we should be identical to what we currently have, except we've
explicliyt scoped was was searched for before.

And it leads to an easy way for people to change public (in the
search path and/or <schema>.<table>) to do other things (although I'm
not saying that's necessarily required or desired either).

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-07 16:47:28 Re: Patch to fix search_path defencies with pg_bench
Previous Message Tom Lane 2009-05-07 16:34:24 Re: Some 8.4 changes needed according to pg_migrator testing