Re: Extension for PostgreSQL cast jsonb to hstore WIP

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?

In response to

Browse pgsql-hackers by date

  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