diff options
author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2023-10-05 10:59:08 +0200 |
---|---|---|
committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2023-10-05 10:59:08 +0200 |
commit | 1c99cde2f3440c59f582d45b251412c9a9b54f62 (patch) | |
tree | b50d690b8c52dbe74ea8e8f14d9051708df20523 /src/backend/access/gist/gistproc.c | |
parent | a8a968a8212ee3ef7f22795c834b33d871fac262 (diff) | |
download | postgresql-1c99cde2f3440c59f582d45b251412c9a9b54f62.tar.gz postgresql-1c99cde2f3440c59f582d45b251412c9a9b54f62.zip |
Improve JsonLexContext's freeability
Previously, the JSON code didn't have to worry too much about freeing
JsonLexContext, because it was never too long-lived. With new features
being added for SQL/JSON this is no longer the case. Add a routine
that knows how to free this struct and apply that to a few places, to
prevent this from becoming problematic.
At the same time, we change the API of makeJsonLexContextCstringLen to
make it receive a pointer to JsonLexContext for callers that want it to
be stack-allocated; it can also be passed as NULL to get the original
behavior of a palloc'ed one.
This also causes an ABI break due to the addition of flags to
JsonLexContext, so we can't easily backpatch it. AFAICS that's not much
of a problem; apparently some leaks might exist in JSON usage of
text-search, for example via json_to_tsvector, but I haven't seen any
complaints about that.
Per Coverity complaint about datum_to_jsonb_internal().
Discussion: https://postgr.es/m/20230808174110.oq3iymllsv6amkih@alvherre.pgsql
Diffstat (limited to 'src/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions