Re: Extract numeric filed in JSONB more effectively

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extract numeric filed in JSONB more effectively
Date: 2023-08-21 01:31:56
Message-ID: CAKU4AWpnFXYXtfOQp_QdQ7RwCD-d+qzyZKdNygc+9DY8bveVYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 19, 2023 at 3:09 AM Chapman Flack <chap(at)anastigmatix(dot)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

Attachment Content-Type Size
v10-0001-optimize-casting-jsonb-to-a-given-type.patch application/octet-stream 31.7 KB
v10-0002-convert-anyelement-to-internal.patch application/octet-stream 11.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiro Ikeda 2023-08-21 02:04:23 Re: Rethink the wait event names for postgres_fdw, dblink and etc
Previous Message Jonathan S. Katz 2023-08-21 01:09:56 Re: PostgreSQL 16 RC1 + GA release dates