On 10-08-19 05:29 PM, Christopher Browne wrote:
> Brad Nicholson<bnichols at ca.afilias.info>  writes:
>>   On 10-08-19 02:58 PM, Christopher Browne wrote:
>>> Actually, that suggests to me a *bit* more sophisticated semantics...
>>>
>>> EXECUTE SCRIPT works two ways:
>>>
>>>     1.  If the DDL begins with LOCK statements, then EXECUTE SCRIPT begins
>>>     by locking those tables specified in the LOCK statements.
>>>
>>>     2.  If the DDL begins without any LOCK statements, then EXECUTE SCRIPT
>>>     assumes that *ALL* tables should be locked.
>>>
>> +1 on the idea, -1 on the implementation.  I've never been a fan of
>> magic values that implicitly takes a different code path based on the
>> values detected like this.
>>
>> I would much rather see an extra parameter added to the EXECUTE SCRIPT
>> where you could specify a separate file containing the locks.  If you
>> provide it, Slony uses those, if you don't, it uses it's default
>> locking.  I think this is cleaner from the users perspective.
> Here are a couple approaches to specify the locking, which includes, I
> think, what you suggest:
>
>    3.  An extra parameter to EXECUTE SCRIPT is a quoted comma-separated
>        list of the IDs (as in sl_table.tab_id) of tables to be locked.
>
>        execute script (set id=1, filename='/tmp/ddl-script.sql',
>                        event node=3, tables to lock='1,2,17,29,35');
>
>        While this is somewhat nice in the sense that we can validate (and
>        raise errors, if invalid) that the tables being locked are
>        legitimate ones, the table IDs aren't the most obvious thing in
>        the world to look up.
>

If you ever need to lock tables that are not replicated, this approach 
won't work.

>    4.  An extra parameter to EXECUTE SCRIPT indicates the filename of
>        a file containing the LOCK TABLE requests.
>
>        execute script (set id=1, filename='/tmp/ddl-script.sql',
>                        event node=3, lockfile='/tmp/locks.sql');
>
>        I think this is more or less what you're suggesting, and it seems
>        fine to me.
>
> I think I like "#4" the best of any of the options, thus far.  I'm not
> sure Jan/Steve have seen them, so it's premature to treat it as
> "decided."
>

I like #4 as well.

-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.