> On Wed, Oct 26, 2005 at 10:20:27AM +1000, Philip Yarra wrote:
>> tables differentiated only by the case of the name (e.g. ACCOUNT,
>> account and
>> aCcOuNt) in the same database and schema. I reckon that's a corner-case,
>> but
>> I'm willing to revise my opinion if someone can provide me with a
>> real-life
>> example.
>
> It makes no difference if it's a corner case.  Slony is supposed to
> provide generic support, which means we _have_ to support this.

I think this implies that the perl tools need to do some extra quoting.

They consciously do NOT interact with the database, but rather just
generate slonik scripts.  Someone could argue to change that, but they had
better argue compellingly, as this would impose a pretty big addition of
complexity.

It seems even less likely that changing slonik to try to be "intelligent"
about this would take place.  In effect, Philip is suggesting what is a
loose sort of "DWIM" (Do What I Meant).  I daresay that the PostgreSQL
community has a little reluctance to do that, particularly as one of those
would-be "competing products" strives rather hard to have a DWIM user
interface as their "expression of superiority."

>> Well yeah, this is my point: I'm a software developer, I'm used to
>> things
>> blowing up in my face. It still took me by surprise, and cost me time
>> figuring out why it occurred. I suspect people less-accustomed to
>> PostgreSQL
>> might take longer to figure it out, or worse yet, give up on using
>> PostgreSQL
>> and Slony. I want to remove obstacles to adoption.
>
> Right.  It appears to me that this is a documentation issue.

... Which presumably puts it onto my plate :-).

I have committed a couple changes to the documentation in the last 24
hours, in addition to starting work on a Wiki that Darcy graciously set up
yesterday to help collaboration on:

a) A more proper Release Process Checklist

b) A central list of "How do I do X with Slony-I?"  Documentation for how
to do plenty of things is available, *somewhere* in the admin guide, but
actions are generally explained adjacent to what component or command they
relate to.  This list will, in effect, provide a secondary index...

There is a section that talks about the altperl tools; I'll see about
adding something there...