http://www.slony.info/bugzilla/show_bug.cgi?id=153

--- Comment #2 from Stuart Bishop <stuart at stuartbishop.net> 2010-08-26 20:42:03 PDT ---
> 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?

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.