>> slonik is for the most part a wrapper to the plpgsql functions within >> the >> database, so the idea of making slonc an interactive client is not as >> far >> fetched as you may first think. >> > > But this is a disadvantage as well: > slonik's dialect isn't very user-friendly regarding to an interactive > language, > you have to play with cluster id's, table id's and node id's and this > makes it > a little bit "rough"....btw. this bothers me in the altperl scripts as > well
One of my ideas for Slony-I 1.1 had been to introduce the notion of "node names." I discovered that managing this was *way* more difficult than it appeared. Adding and managing names would introduce a great deal of complications. Korry Douglas then sailed in as a "savior", to my mind, when he contributed code for keywords 'include' and 'define'. That allows having symbolic names in scripts, albeit in a way that is invisible to the cluster's direct configuration... It seems to me that your "interactive slonc" will need to have a LOT of internal mechanism in order to work. You would need to fairly much define a full-scale language with variables, operators for "string smashing," and such like. There are two directions that can take you: 1. You wind up having designed a new scripting language with a REPL. <http://en.wikipedia.org/wiki/Read-eval-print_loop> Seems like a big mistake to me to start such a project from scratch. 2. You embed Slony-I functions into some existing REPL-based scripting language. Which more or less implies embedding it into Python or into some flavour of Lisp. I'd be interested to see that; I'm not sure that either option will be forcibly considered "user friendly." I'm not saying "don't bother trying," but it would be a mistake to take the project on without a reasonably clear idea of the scope... _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
