Re: Extract numeric filed in JSONB more effectively
Andy Fan <zhihui.fan1213@gmail.com>
From: Andy Fan <zhihui.fan1213@gmail.com>
To: Chapman Flack <chap@anastigmatix.net>
Cc: jian he <jian.universality@gmail.com>,
Pavel Stehule <pavel.stehule@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-08-21T01:31:56Z
Lists: pgsql-hackers
Attachments
- v10-0001-optimize-casting-jsonb-to-a-given-type.patch (application/octet-stream) patch v10-0001
- v10-0002-convert-anyelement-to-internal.patch (application/octet-stream) patch v10-0002
On Sat, Aug 19, 2023 at 3:09 AM Chapman Flack <chap@anastigmatix.net> wrote: > On 2023-08-18 14:50, Chapman Flack wrote: > > Now, my guess is EXPLAIN is complaining when it sees the Const > > of type internal, and doesn't know how to show that value. > > Perhaps makeRelabelType is the answer there, too: what if the > > Const has Oid type, so EXPLAIN can show it, and what's inserted > > as the function argument is a relabel node saying it's internal? > Simply changing the Const to be of type Oid makes EXPLAIN happy, > and nothing ever says "hey, why are you passing this oid for an > arg that wants internal?". This is without adding any relabel > nodes anywhere. > Highlighting the user case of makeRelableType is interesting! But using the Oid directly looks more promising for this question IMO, it looks like: "you said we can put anything in this arg, so I put an OID const here", seems nothing is wrong. Compared with the makeRelableType method, I think the current method is more straightforward. Compared with anyelement, it avoids the creation of makeDummyConst which I'm not sure the implementation is alway correct. So I am pretty inclined to this way! v10 attached. -- Best Regards Andy Fan
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add trailing commas to enum definitions
- 611806cd726f 17.0 cited