On Mon, 16 Dec 2024 at 19:32, Tom Lane <t...@sss.pgh.pa.us> wrote: > No, sorry, I was just illustrating the behavior with HEAD. > The important part of this is not the assigned alias > but the visible cast.
Then I don't think I understand what you're trying to say. While I think it would be good to not have an explicit cast impact the explicit casts in a subscript as well, it does seem like a rather niche edge case for people to write a query where that would matter. If you're doing such explicit casts, you probably also want to set an explicit alias. Case in point being ruleutils, where it explicitizes both the implicit cast, and the implicit column alias. > > So what would you want here? Do you want these columns to be called 2 > > and 3? > > No!! Good, then we agree on that at least. > > One thing that I didn't see you explicitly say: Do you agree that the > > new column names are actually better than the old ones? > > No, I'm not at all convinced of that. For these examples > I'd prefer something like "data_a", "data_b", etc. I did consider that naming scheme as well, but there are a few reasons: 1. That same naming scheme holds just as well for fields of composite types. It seems inconsistent to only do it for subscripts. Our logic now is to take the last field name in a series of field names. My POC patch basically extends that to be the last field name OR string-literal subscript. (to be clear changing the default column names for fields of composite types like this seems out of the question to me with regards to the amount of impact). 2. There's a hard limit of 63 characters in a column name due to NAMEDATALEN, so putting the whole path in there won't fit in case of somewhat long subscript names. 3. Even if we'd have unlimited length, now you end up with common prefixes if you select multiple fields. 4. For the custom type that I'm implementing the subscripting for, I really don't want such a prefix. > That approach might also make it more palatable to process integer > literals this way (i.e. "data_2" etc), though I am not sure we want > to do that because of the increased blast radius. I agree, that would be nice, but I don't think that's worth the additional blast radius.
