On Tue, Apr 19, 2011 at 11:56 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> I do think that DO covers a lot of the same territory that could
>> usefully be addressed by a more powerful backslash-command language in
>> psql. It's in some ways quite a bit more powerful, because it's
>> available from any client, and it knows about data types, which psql
>> doesn't, so things like \while are going to be awkward (what
>> comparison semantics will it use?). The only advantage I can really
>> see to doing that stuff on the client side is that you could do things
>> like \connect and \prompt that wouldn't make sense on the server side.
>
> Well, you missed one big advantage: with DO you are 'one transaction'
> limited -- this makes it unsuitable for certain classes of maintenance
> tasks (no vacuum etc), creating a lot of tables, long running (even
> infinite) scripts etc. It would remain a boutique feature more or
> less, but would add a lot of value to psql scripting which is
> particularly suffering from adequate error handling.
Ah, good point. I assume you mean "inadequate" rather than "adequate".
> Ultimately if you have stored procedures then you have the best of
> both worlds especially if you had a method of sending the procedure
> body as you can with functions and DO.
Also true.
> A psql meta language would do
> in a pinch though, and it would be a lot easier to implement -- don't
> like the bifurcated implementation (psql and pgbench) though.
Yeah. I was wondering if anyone was gung-ho enough about this to
implement some kind of library that both programs could draw on.
It probably wouldn't be super-hard, if we could agree on a rough design.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company