From: Claudio V. C. <cv...@us...> - 2001-12-10 07:32:54
|
Neil, regarding your latest changes through fb-checkins: string = (STR) node->nod_arg [e_udf_name]; + /* how are we supposed to tell which type of nod_udf this is ?? */ + if (string->str_data[0] == NULL) + PRINTF("%s\"\n",((UDF) node->nod_arg[0])->udf_name); + else + PRINTF ("%s\"\n", string->str_data); What's the pattern for the two types of UDFs? I thought the name always comes in a nod_arg at index e_udf_name, but your code proves other fact. Isn't there another place in the code when the udf name is pushed into the BLR stream? Since e_udf_name is zero in practice, I understand your problem is between char *s = ((STR) node->nod_arg [0])->str_data; and char *s = ((UDF)node->nod_arg[0])->udf_name Strange problem. One possible source could be our dsql parser that might be generating different nodes. The other explanation is that you're in a map when you have aggregate functions or sub-selects, have a look at pass1.c when a name is assigned to each column, there's a long if-else-if construction. In practice, you can determine the type of the node by looking at nod->nod_type (high level type) and nod->nod_header.blk_type (what the allocator knows) The types that the DSQL allocator knows are in dsql\blk.h, you could test such info; there are type_udf and type_str. I'm still wondering why other places of the code don't seem to have that same problem. C. --------- Claudio Valderrama C. Ingeniero en Informática - Consultor independiente http://www.cvalde.com - http://www.firebirdSQL.org |