Christopher Kings-Lynne <chris.kings-lynne@calorieking.com> writes:
>> I really think this is backwards: you should be looking for the .sql
>> files. Every module will have a .sql file, not every one will need a
>> .so file. See followup thread in -hackers where we're trying to hash
>> out design details.
> Not in this case.
> Basically Slony has the concept of installing a node into a server. You
> can have multiple ones of them - different schemas. So, I'd like to be
> able to detect that the .so is there, and then offer an "install node"
> feature where WE execute the SQL on their behalf, with all the
> complicated string substitions already done.
No, Slony is going to have to adapt to modules, not vice versa. We are
*not* designing the module feature on the assumption that every module
has some C functions at its core. That would be a shameful restriction
of the potential applications.
It might be that some way to parameterize the SQL scripts would be handy
(the question about which schema to install into comes to mind) ... but
that doesn't justify making a .so file the central part of the module
concept.
But again, this is the wrong list. Please contribute to the
"Generalized concept of modules" thread in -hackers.
regards, tom lane