> On January 27, 2005 03:52 pm, Christopher Browne wrote:
>> Darcy Buskermolen wrote:
>> >On January 27, 2005 02:06 pm, Christopher Browne wrote:
>> >
>> >Chis, I'm running this test on my 8.1 box, and it works fine.
>> >the problem perhaps is related to other changes I made in CVS yesterday
>> ?.
>> >Try a fresh checkout + ./configure and see if theproblem goes away.
>> >I made a change to slonik.c that now expects the "sed" to be passed in
>> as
>> > a -Ddefine.  this was done to some install I admin not having sed in
>> the
>> > path, and slonik would just do strange things.
>>
>> Ah.  I'm doubtless doing something "dodgy" in my installation.
>>
>> And I'll be musing about the merits of maybe using cpp or m4 to do
>> name/id mappings...  Trying to nearly interchangeably use names or
>> numbers makes for some thorny problems that "macro rewriting" would make
>> go away.  I have been warned that I might get shunned by some people if
>> I try m4...
>
> I'll be one of them on that list when it comes to m4.
>
> Hmmm.. In all seriousness, how you envisioning the named objects working?
> Since all of the critical code is implemented in plpgsql, can't we just
> add a
> name to the relevent objects, and have the action function check the name
> column first, and if no matches, assume I passed in an id and cheke the
> id,
> and if it's not found then we just exist as normal ? It should be trvial
> to
> have slonik parser accept one or the other but not both.   or Am I missing
> something really simple here?

It's trivial in the parser (well, as "trivial" as Yacc gets).

It's not a problem to apply names to nodes.  Attaching it to INIT CLUSTER
and STORE NODE was only tricky insofar as the parser.y code and slonik.c
code separates different parts of the evaluation loop.  Creating a RENAME
NODE command was similarly relatively easy.  Those are all the operations
that are easy because they have ID and name right together.

The problem comes as soon as you get past that.  Each of the operators
that uses node numbers uses that node number to determine which node it's
supposed to talk to.  If you haven't already got that mapping in memory,
you wind up needing some sort of "ESP protocol" because the DB you should
be asking the node number from is the one for which all you have is the
node name.  Oops.

Conceivably, I could rummage through each of the "admin conninfo"
instances to see if I can get mappings, but that leaves the further
entertainment of what to do if events to update the node names are in
process; I can get ambiguous answers even though they oughtn't be
ambiguous.

The m4:

define(`node_srvrds005', `1')
define(`node_srvrds004', `4')
define(`node_srvrds003', `3')
define(`node_srvrds007', `78')
define(`ds501', `501')

causes the following:

node node_srvrds005 admin conninfo 'dsn=foo';
node node_srvrds004 admin conninfo 'dsn=bar';
node node_srvrds003 admin conninfo 'dsn=foo';
node node_srvrds007 admin conninfo 'dsn=foo';
node ds501 admin conninfo 'dsn=foo';

create cluster	info (id=node_srvrds005);
store node (id=node_srvrds004, comment='Node on ds004', spool='f');
store node (id=node_srvrds003, comment='Node on ds003', spool='f');
store node (id=node_srvrds007, comment='Node on ds007', spool='t');
store node (id=ds501, comment='Node on ds-501', spool='f');

to expand to...

cbbrowne at wolfe:/usr/share/doc/m4-doc> m4 /tmp/nodes.m4 /tmp/rewrite

node 1 admin conninfo 'dsn=foo';
node 4 admin conninfo 'dsn=bar';
node 3 admin conninfo 'dsn=foo';
node 78 admin conninfo 'dsn=foo';
node 501 admin conninfo 'dsn=foo';

create cluster  info (id=1);
store node (id=4, comment='Node on ds004', spool='f');
store node (id=3, comment='Node on ds003', spool='f');
store node (id=78, comment='Node on ds007', spool='t');
store node (id=501, comment='Node on ds-501', spool='f');

For all that m4 is supposedly pretty heinous, I think I can live with that.

Alternatively:

cbbrowne at wolfe:/usr/share/doc/m4-doc> m4 -Dnode_srvrds005=1
-Dnode_srvrds004=4 -Dnode_srvrds003=3 -Dnode_srvrds007=78 -Dds501=501
/tmp/rewrite
node 1 admin conninfo 'dsn=foo';
node 4 admin conninfo 'dsn=bar';
node 3 admin conninfo 'dsn=foo';
node 78 admin conninfo 'dsn=foo';
node 501 admin conninfo 'dsn=foo';

create cluster  info (id=1);
store node (id=4, comment='Node on ds004', spool='f');
store node (id=3, comment='Node on ds003', spool='f');
store node (id=78, comment='Node on ds007', spool='t');
store node (id=501, comment='Node on ds-501', spool='f');

With that approach, I can drop the parser changes like I would a dead skunk.

I have NO intention of suggesting the use of anything more sophisticated
than the above sorts of macro rewriting.  None of it will be acceptable to
"Windows folk," but Jan suggested the thought that "WinFolk" probably
wouldn't be too excited about slonik in the first place.  Maybe cpp is
more suitable than m4; I daresay I don't care all that much.

That's the 'Thursday nite' view...