"Brendan Jurd" <direvus@gmail.com> writes: > This approach is making sense to me, but I've run into a bit of a > dependency issue. A_Const does indeed have a slot for typecasts by > way of a TypeName member. A_Const and TypeName are both defined in > parsenodes.h, whereas ArrayExpr is defined in primnodes.h. So > unfortunately I can't just add a TypeName member to ArrayExpr. That would be quite the wrong thing to do anyway, since ArrayExpr is a run-time representation and shouldn't have any such thing attached to it. What you probably need is a separate parse-time representation of ARRAY[], a la the difference between A_Const and Const. Another possibility is to just hack up a private communication path between transformExpr and transformArrayExpr, ie when you see TypeCast check to see if its argument is ArrayExpr and do something different. This would be a mite klugy but it'd be a much smaller patch that way. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

"Brendan Jurd" <direvus@gmail.com> writes: > I'm not 100% clear on what the A_ prefix signifies ... is A_ArrayExpr > a good name for the parse-time structure? Yeah, might as well use that for consistency. The A_ doesn't seem very meaningful to me either, but I don't want to rename the existing examples ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

"Brendan Jurd" <direvus@gmail.com> writes: > So far I've only considered the '::' cast syntax suggested in the > original proposal, e.g.: > ARRAY[]::text[] > I wonder whether we are also interested in catching CAST(), e.g.: > CAST(ARRAY[] AS text[]) I think you'll find that it's just about impossible to not handle both, because they look the same after the grammar gets done. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

"Brendan Jurd" <direvus@gmail.com> writes: > Now I'm thinking I leave the grammar rules alone (apart from making it > legal to specify an empty list of elements), and instead push the > typename down into the child node from makeTypeCast(), if the child is > an A_ArrayExpr. Does that work better? Actually, if you do that you might as well forego the separate node type (which requires a nontrivial amount of infrastructure). I think it would work just about as well to have transformExpr check whether the argument of a TypeCast is an ArrayExpr, and if so call transformArrayExpr directly from there, passing the TypeName as an additional argument. Kinda ugly, but not really any worse than the way A_Const is handled in that same routine. (In fact, we could use the same technique to get rid of the typename field in A_Const ... might be worth doing?) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

"Brendan Jurd" <direvus@gmail.com> writes: > I actually thought that A_ArrayExpr would be a good addition even if > you ignore the matter of typecasting. It always seemed weird to me > that the parser generates an ArrayExpr directly. ArrayExpr has a > bunch of members that are only set by the transform; all the parser > does is set the 'elements' member. Well, that's a reasonable argument. And now that I think about it, a parser-only node type doesn't have nearly the support overhead that a full-fledged executable node does. So no objection to A_ArrayExpr if you want to do that. > I had a bit of a dig into this. A_Const->typename gets set directly > by the parse paths for "INTERVAL [(int)] string [interval range]". In > fact, as far as I can tell that's the _only_ place A_Const->typename > gets used at all. Uh, you missed quite a lot of others ... see CURRENT_DATE and a lot of other productions. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

Martijn van Oosterhout <kleptog@svana.org> writes: >> 1) How should we determine whether the array is multidimensional if we >> know the type in advance? > Well, given the array should be regular you should be able to just look > at the first element, if it's a array look at it's first element, etc > to determine the dimensions. This'll be fairly quick. How does that work with non-constant array constructor members? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly