The PostgreSQL query analyzer -- the piece of the backend which transforms the SQL queries you write into structured information which the planner can optimize and the executor can, uh, execute -- has a number of functions which are all named vaguely like "make_op()". (Think make_op(), make_array_op(), make_scalar_array_op(), &c.) This family is, predictably, used to generate record-specialized arithmetic functions, e.g., "add column A in this row to column B in the same row". There are about six of them, and they all return a pointer to an Expr struct.
I need to create a new make_op() function, so of course I looked at the definition of this struct type. I was vaguely horrified to see
So I took a closer look at one of the make_op() functions (make_scalar_array_op(), for those of you playing along at home) and noticed another declaration: ScalarArrayOpExpr *result;. The return statement? return (Expr *) result;.
Can you say "even more horrified"? My God. If they wanted to cast through a void*, they could have just cast through a void* and had done with it. libgdome2 at least has the decency to do that, though they're actually doing it via glib, which buries its void* casting through enough layers of typedef indirection that to the uninitiated (read: people who haven't bothered to dig through all that source) it almost looks like there's some type safety going on.
To the PGDG's credit, the comments say that this is mainly for purposes of documentation (i.e., tracking where nodes are getting generated, or something like that, I guess). But they also refer to Expr as a "superclass". BAD NAUGHTY PGDG. NO BISCUIT.
I can understand the desire to give C some kind of type checking/safety. But this is the third time I've seen it (not counting C++), and the second time I've seen it done badly. (Zend, we will let you live. This time.) "Badly," in this case, means "in a way that suggests some kind of typesafety, but is only providing an illusion."
I fear they are losing the substance for grasping at the shadow.
I need to create a new make_op() function, so of course I looked at the definition of this struct type. I was vaguely horrified to see
typedef struct Expr
{
NodeTag type;
} Expr;WTF, mate? Where's all that column identifier information? For that matter, where's the fucking operator?So I took a closer look at one of the make_op() functions (make_scalar_array_op(), for those of you playing along at home) and noticed another declaration: ScalarArrayOpExpr *result;. The return statement? return (Expr *) result;.
Can you say "even more horrified"? My God. If they wanted to cast through a void*, they could have just cast through a void* and had done with it. libgdome2 at least has the decency to do that, though they're actually doing it via glib, which buries its void* casting through enough layers of typedef indirection that to the uninitiated (read: people who haven't bothered to dig through all that source) it almost looks like there's some type safety going on.
To the PGDG's credit, the comments say that this is mainly for purposes of documentation (i.e., tracking where nodes are getting generated, or something like that, I guess). But they also refer to Expr as a "superclass". BAD NAUGHTY PGDG. NO BISCUIT.
I can understand the desire to give C some kind of type checking/safety. But this is the third time I've seen it (not counting C++), and the second time I've seen it done badly. (Zend, we will let you live. This time.) "Badly," in this case, means "in a way that suggests some kind of typesafety, but is only providing an illusion."
I fear they are losing the substance for grasping at the shadow.
- Mood:peevish
I have written compiler-specific code. Cf. "mood".
- Mood:vaguely unclean
