On Tue, Apr 19, 2011 at 11:56 AM, Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
