From: | Stepan Neretin <sncfmgg(at)gmail(dot)com> |
---|---|
To: | Антуан Виолин <violin(dot)antuan(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, ShadowGhost <violin05082003(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Extension for PostgreSQL cast jsonb to hstore WIP |
Date: | 2024-07-15 07:54:10 |
Message-ID: | CAN-sa+DAVYda5zCUXXZ65=ShLo9SzkRh-_YD-y__PnBSxcZmaw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 15, 2024 at 12:44 PM Антуан Виолин <violin(dot)antuan(at)gmail(dot)com>
wrote:
> On 2024-04-03 Wn 04:21, Andrew Dunstan
>
>> I don't think a cast that doesn't cater for all the forms json can take
>> is going to work very well. At the very least you would need to error out
>> in cases you didn't want to cover, and have tests for all of those errors.
>> But the above is only a tiny fraction of those. If the error cases are
>> going to be so much more than the cases that work it seems a bit pointless.
>>
> Hi everyone
> I changed my mail account to be officially displayed in the correspondence.
> I also made an error conclusion if we are given an incorrect value. I
> believe that such a cast is needed by PostgreSQL since we already have
> several incomplete casts, but they perform their duties well and help in
> the right situations.
>
> cheers
> Antoine Violin
>
> Antoine
>
> On Mon, Jul 15, 2024 at 12:42 PM Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
>
>>
>> On 2024-04-02 Tu 11:43, ShadowGhost wrote:
>>
>> At the moment, this cast supports only these structures, as it was enough
>> for my tasks:
>> {str:numeric}
>> {str:str}
>> {str:bool}
>> {str:null}
>> But it's a great idea and I'll think about implementing it.
>>
>>
>> Please don't top-post on the PostgreSQL lists. See
>> <https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics>
>> <https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics>
>>
>> I don't think a cast that doesn't cater for all the forms json can take
>> is going to work very well. At the very least you would need to error out
>> in cases you didn't want to cover, and have tests for all of those errors.
>> But the above is only a tiny fraction of those. If the error cases are
>> going to be so much more than the cases that work it seems a bit pointless.
>>
>>
>> cheers
>>
>>
>> andrew
>>
>> --
>> Andrew Dunstan
>> EDB: https://www.enterprisedb.com
>>
>>
Hi! I agree in some cases this cast can be useful.
I Have several comments about the patch:
1)I think we should call pfree on pairs(now we call palloc, but not pfree)
2)I think we should add error handling of load_external_function or maybe
rewrite using of DirectFunctionCall
3)i think we need replace all strdup occurences to pstrdup
4)why such a complex system , you first make global variables there to load
a link to functions there, and then wrap this pointer to a function through
a define?
5) postgres=# SELECT '{"aaa": "first_value", "aaa":
"second_value"}'::jsonb::hstore;
hstore
-----------------------
"aaa"=>"second_value"
(1 row)
is it documented behaviour?
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2024-07-15 07:55:26 | Re: Injection point locking |
Previous Message | jian he | 2024-07-15 07:35:06 | Re: Re: Removing unneeded self joins |