On Mon, 16 Dec 2024 at 21:55, Tom Lane wrote:
> Oh, well if you're willing to cheat like that, sure ;-). I was
> speaking of replacing the existing logic with something that looked
> only at the post-analysis tree.
Yeah, alright. That's not really something that I think we can do
without introdu
Jelte Fennema-Nio writes:
> On Mon, 16 Dec 2024 at 21:09, Tom Lane wrote:
>> However, after thinking a little longer I seem to recall that we've
>> previously looked into the idea of deriving the default aliases from
>> the post-parse-analysis tree. We gave up because there were too many
>> case
On Mon, 16 Dec 2024 at 21:09, Tom Lane wrote:
> Hm. If we made this behavior type-specific then you could have what
> you want without having to break any existing expectations at all.
Yeah, I agree that's definitely the safest. So, that's basically
option 2 I described in my first email, right?
Jelte Fennema-Nio writes:
> 4. For the custom type that I'm implementing the subscripting for, I
> really don't want such a prefix.
Hm. If we made this behavior type-specific then you could have what
you want without having to break any existing expectations at all.
However, after thinking a li
On Mon, 16 Dec 2024 at 19:32, Tom Lane 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 explic
Jelte Fennema-Nio writes:
> On Mon, 16 Dec 2024 at 16:34, Tom Lane wrote:
>> View definition:
>> SELECT data['a'::text] AS data
>> FROM tj;
> Are you sure you ran this with my patch?
No, sorry, I was just illustrating the behavior with HEAD.
The important part of this is not the assigned alias
On Mon, 16 Dec 2024 at 16:34, Tom Lane wrote:
> I dunno, this seems to be putting an undue amount of emphasis on
> one very specific usage pattern. Why should it matter whether
> the subscripts are string literals or not? What will happen when
> ruleutils decides to dump those expressions with th
Jelte Fennema-Nio writes:
> SELECT data['a'], data['b'], data['c'] FROM tj;
> Gives the following output:
> data │ data │data
> ──┼───┼
> 123 │ "abc" │ [123, 456]
> I'd much rather have it output:
> a│ b │c
> ──┼───┼
> 123 │ "abc"
I'm working on implementing subscripts for a custom type, but one
usability issue I'm running into is that the default column names for
subscript expressions are rather bad.
The easiest way to show this is with json. Running the following in psql:
CREATE TABLE tj(data jsonb);
INSERT INTO tj value
