On Thu, Apr 25, 2024 at 12:34 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Yes. We've heard that argument about "this only affects extensions > that choose to use it" before, and it's nonsense. As soon as you > extend system-wide APIs, the consequences are system-wide: everybody > has to cope with the new definition.
Sure. Any new feature has this problem to some extent. > Uh, no. My point is that if you make a custom output function > for "type complex (real float8, imaginary float8)", that function > will probably crash pretty hard if what it's handed is something > other than two float8s. But there is nothing to stop somebody > from trying to ALTER the type to be two numerics or whatever. > Conversely, the type's custom input function would likely keep on > producing two float8s, yielding corrupt data so far as the rest > of the system is concerned. I'm not sure I really buy this. Changing the column definitions amounts to changing the on-disk format, and no data type can survive a change to the on-disk format without updating the I/O functions to match. > I think that to the extent that there's a need for custom I/O > of something like this, it should be handled by bespoke types, > similar to (say) type point. I somewhat agree with this. The main disadvantage of that approach is that you lose the ability to directly refer to the members, which in some cases would be quite nice. I bet a lot of people would enjoy being able to write my_point.x and my_point.y instead of my_point[0] and my_point[1], for example. But maybe the solution to that is not $SUBJECT. A related problem is that, even if my_point behaved like a composite type, you'd have to write (my_point).x and (my_point).y to avoid something like: ERROR: missing FROM-clause entry for table "my_point" I think it's confusing and counterintuitive that putting parentheses around a subexpression completely changes the meaning. I don't know of any other programming language that behaves that way, and I find the way the "indirection" productions are coded in gram.y to be highly questionable. I suspect everything we currently treat as an indirection_el should instead be a way of constructing a new a_expr or c_expr or something like that, but I strongly suspect if I try to make the work I'll discover horrible problems I can't fix. Still, it's awful. -- Robert Haas EDB: http://www.enterprisedb.com
