--On Freitag, Februar 16, 2007 08:37:18 -0500 [EMAIL PROTECTED]
wrote:
[...]
>
>> I don't think this would be that hard to divide slonik in this fashion
>> the code is mostly divided like that anyway. Writing a Perl module
>> wrapper that exposes the API shouldn't be that difficult either (I
>> suspect the same
>> could be done for tcl). Would that make the altperl tools easier to
>> maintain?
>
> I think this requires creating a new set of Perl tools, because using the
> API (that is, in truth, already there; pgAdmin uses it...) would require
> opening multiple connections and introducing DBI to the mix.
>
> The design of "altperl" has *very* consciously left DBI *out*; it
> consciously *does not* interact with the cluster (with a couple of
> inconspicuous exceptions).
I completely agree. The "altperl" design by relying on slonik and
auto-generating
slonik-commandscripts is simple, easy to test and without significant
overhead.
What i want is a simple-to-maintain, and re-usable well-designed interface
for
this functionality, without loosing too many of the benefits the current
altperl
implementation offers.
>
> I would argue against quietly messing with "altperl." I think it would be
> a bad idea to try to quietly evolve altperl into something else. At some
> point, that leads to a very painful change of understanding of what it is,
> and some serious disputing over that.
Agreed, again.
[...]
--
Thanks
Bernd
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
