At 17:05 16/11/2007, hubert depesz lubaczewski wrote:
>so - combining these two statements would generate "trigger knows *real*
>column names".

It actually finds them, yes (reading the list of attributes of the 
table in pg_attributes, IIRC).

>knowing this - why can't we/slony abandon these "funny little symbols"
>and store key-column-names directly?

They're actually used to find which columns are part of the key used 
for replication (the PK usually) and which are not. This is necessary 
for UPDATE statements (non-key columns go into the SET clause, key 
columns go into the WHERE clause) and DELETE statements (only key 
columns are used in the WHERE clause).

>please do not take this question as offensive. i'm merely asking because
>i dont udnerstand, and in my understanding this would lead to much
>easier working with slony (i.e. no "execute script" neccessity for
>adding columns).

As stated in an earlier post, you don't really need to, as long as 
your new column doesn't have a constraint, default value, or anything 
like that (just a simple "name type" and nothing else). Just add the 
column on the slaves, then add a "v" to the trigger as explained in 
that post, then add the column on the source. Et voila.

Indeed a quick patch would remove the requirement to update the 
trigger, but that's another story.

In any other situation (default values, constraints...), it is (very 
often) important that at least the change be done at the same point 
in the event stream on all machines in the set, and it is therefore 
necessary to use the EXECUTE SCRIPT system.

Hope that helps,

Jacques.