Yes, it would be good to use the site node name entry (after checking that the method defined for site_node indeed uses that column.)
It would also be good to store the url as a field in the site node table, calculating it when the node is mounted or renamed. This could be done via trigger.
This is code we've inherited from the original aD 4.2. There are many, many examples of queries like this that we should clean up as time permits. So far we've been concentrating on big things, i.e. I'm about half-way through my reimplementation of permissions, something that affects *everything*.
But patches to fix/improve suboptimal queries or datamodel choices are *always* more than welcome, though for obvious reasons those that fix both Oracle and PG rather than just one or the other are a heck of a lot more likely to get included ASAP. And if there's a datamodel change (i.e. to maintain site_node.url as a column in the table rather than compute it everytime) then we need upgrade scripts, too ...
Note though that this isn't a very good argument for extending the basic object with extra data. The code here *knows* that it is building a context bar from site node information. It doesn't fit the criteria of "code that examines objects extracting data without any type-specific knowledge of the objects" which in my mind would justify extending the object datamodel.
