I find it very useful to be able to use the shell to include chunks of slonik script generated by scripts: $ slonik <<EOM `./preamble.py` echo 'Do stuff'; EOM Hello from preamble Do stuff It would be great if I did not have to use the shell to do the inclusion, and instead if slonik supported the back tick syntax internally. $ cat foo.sk `./preamble.py` echo 'Do stuff'; EOM $ slonik foo.sk Hello from preamble Do stuff
You'd like slonik to take ``, expand it via system() (or similar), and then execute it? This seems like a rather large expansion of scope for what's intended to be a "Little Language." There's some thinking out there that slonik is already a bit too big, and that we should be considering eliminating it in favour of just running the underlying stored functions. There's a bit of a problem with that for some operations that have a lot more functionality than "just stored functions" (notably: store node, lock set, execute script, wait for event, set add table), but, in any case, there's certainly thinking towards "simplify slonik." One of the failures, as it were, of the project is that we were expecting that a management GUI would emerge, so that the need for slonik might wither away. Obviously not the case ;-). I'm not particularly keen on trying to turn slonik into a more full-fledged programming language, though.
> You'd like slonik to take ``, expand it via system() (or similar), and then > execute it? Yes. This allows me to embed commands that can only be determined at run time in a slonik script. The preamble is the most common example of this - I can run identical scripts on our staging and production environments. I first picked up the idea of using shell expansion from examples on the web, so I'm not the only one doing things this way. > This seems like a rather large expansion of scope for what's intended to be a > "Little Language." > > There's some thinking out there that slonik is already a bit too big, and that > we should be considering eliminating it in favour of just running the > underlying stored functions. > > There's a bit of a problem with that for some operations that have a lot more > functionality than "just stored functions" (notably: store node, lock set, > execute script, wait for event, set add table), but, in any case, there's > certainly thinking towards "simplify slonik." So I have developers running non-replicated systems, buildbots running non-replicated on ec2, replicated staging systems, replicated production systems. Our database schema is highly agile, with database patches being added by developers and a tool that applies these patches. It has to be automated so a management GUI is useless to me. I have the choice of generating slonik scripts, or generating SQL that invokes the stored functions. Using the raw stored functions seemed very problematic - slonik handles the surprising details such as connecting to the right node to run a function, when to commit, when to wait for propagation, how to recover from failure etc. slonik seems the less surprising, less error prone and more readable approach. > One of the failures, as it were, of the project is that we were expecting that > a management GUI would emerge, so that the need for slonik might wither away. > Obviously not the case ;-). I'm not particularly keen on trying to turn slonik > into a more full-fledged programming language, though. My systems have to be automated and are running on the other side of the planet, so a management GUI is pretty much useless to me. I agree slonik should not become a full-fledged programming language - better to embed the high level commands into an existing scripting language. libslonik?
A fix for this has been committed in 2.2.0 beta 4 See http://git.postgresql.org/gitweb/?p=slony1-engine.git;a=commit;h=2d0cac59824e4b9ad511244a6e3fe9863da6d69e and the merge commit http://git.postgresql.org/gitweb/?p=slony1-engine.git;a=commit;h=4f3fad39db7fc316a3e0b84e4d837bf5d884748b
Please ignore the previous comment/commit, it applies to the wrong bug
http://www.memonic.com/user/pharmacy/id/1Fzde