From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extract numeric filed in JSONB more effectively |
Date: | 2023-08-03 14:27:34 |
Message-ID: | CAKU4AWp8ab61e96v57OaB-Gm1bMfBNVLVy+s17U6_Ne3veB84g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi:
> If you use explicit cast, then the code should not be hard, in the
> rewrite stage all information should be known.
>
Can you point to me where the code is for the XML stuff? I thought
this is a bad idea but I may accept it if some existing code does
such a thing already. "such thing" is typeA:typeB is
converted something else but user can't find out an entry in
pg_cast for typeA to typeB.
> It would be cool but still I didn't see a way to do that without making
>> something else complex.
>>
>
> The custom @-> operator you can implement in your own custom extension.
> Builtin solutions should be generic as it is possible.
>
I agree, but actually I think there is no clean way to do it, at least I
dislike the conversion of typeA to typeB in a cast syntax but there
is no entry in pg_cast for it. Are you saying something like this
or I misunderstood you?
>
--
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | Tristan Partin | 2023-08-03 14:30:10 | Re: Improve const use in zlib-using code |
Previous Message | Andy Fan | 2023-08-03 14:02:10 | Re: Fix incorrect start up costs for WindowAgg paths (bug #17862) |