I wrote: > BTW, a different approach that might be worth considering is to say that > the nodetree representation of one of these things *is* a FuncExpr, and > the new magic thing is just that we invent a new CoercionForm value > which causes ruleutils.c to print the expression as a subscripting op. > I'm not quite convinced that that's a good idea --- a "coercion format" > that says "subscript" seems a bit weird --- but it would greatly reduce > the number of places you'd have to touch.
After sleeping on it, that approach is starting to sound better to me. Consider a design like this: * Leave ArrayRef strictly alone, and introduce new infrastructure beside it for non-array containers. That sounds ugly at first, but it has two significant advantages: you don't have to refactor or even touch any array-related code, and you do not have to worry about somebody objecting to the patch because it adds unacceptable overhead to existing array operations. Converting array ops to go through a function-call API surely must add *some* overhead, and at this point we don't have enough info to be certain it would be negligibly small. (Testing the existing patch cannot prove that, since as I noted yesterday, you're missing a lot of plan-time manipulations that need to happen for a generic function call.) * Let the node representation for non-array-container access be FuncExpr with new value(s) of funcformat. You'd need to design the exact representation to be used for the subscript arguments, but that doesn't seem horribly complicated. In this way, you're not on the hook to duplicate all the node-processing infrastructure for either ArrayRef or FuncExpr --- ideally, you won't need to do much more in the core system than provide the parse-time callout and write suitable deparsing logic in ruleutils.c. The ugliness of thinking that "subscripting" is a kind of coercion could be dealt with by changing funcformat to some new enum type named something like, say, FuncDisplayForm. This would require touching all the places that mess with funcformat, but that could be a good thing anyway, because you'd be sure that you'd looked at everything that might need changes. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers