Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON
От | Andrew Dunstan |
---|---|
Тема | Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON |
Дата | |
Msg-id | 547B800F.60309@dunslane.net обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON
|
Список | pgsql-hackers |
On 11/30/2014 11:45 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> what do you want to do about this? In the back branches, exposing a >> function like this would be an API change, wouldn't it? Perhaps there we >> just need to pick up the 100 lines or so involved from json.c and copy >> them into hstore_io.c, suitably modified. In the development branch I >> thing adding the function to the API is the best way. > If we're going to do it by calling some newly-exposed function, I'd be > inclined to fix it the same way in the back branches. Otherwise the > discrepancy between the branches is a big back-patching hazard. > (For instance, if we realize we need to fix a bug in the numeric-parsing > code, what are the odds that we remember to fix hstore's additional copy > in the back branches?) > > The "API break" isn't a big issue imo. The net effect would be that eg > hstore 9.3.6 wouldn't work against a 9.3.5 server. We do that sort of > thing *all the time* --- at least twice in the past year, according to > a quick scan of the commit logs. If you were changing or removing a > function that third-party code might depend on, it'd be problematic, > but an addition has no such risk. > > OK, here's the patch. cheers andrew
Вложения
В списке pgsql-hackers по дате отправления: