From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: user-defined numeric data types triggering ERROR: unsupported type
Date: Sat, 23 Sep 2017 11:27:26 -0400
Message-ID: <24767.1506180446@sss.pgh.pa.us> (raw)
In-Reply-To: <4b444362-4240-49e0-3523-724e5932b060@2ndquadrant.com>
References: <b68441b6-d18f-13ab-b43b-9a72188a4e02@2ndquadrant.com>
<9389.1506003842@sss.pgh.pa.us>
<4b444362-4240-49e0-3523-724e5932b060@2ndquadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>>> [ scalarineqsel may fall over when used by extension operators ]
> What about using two-pronged approach:
> 1) fall back to mid bucket in back branches (9.3 - 10)
> 2) do something smarter (along the lines you outlined) in PG11
Sure. We need to test the fallback case anyway.
>> [ sketch of a more extensible design ]
> Sounds reasonable to me, I guess - I can't really think about anything
> simpler giving us the same flexibility.
Actually, on further thought, that's still too simple. If you look
at convert_string_to_scalar() you'll see it's examining all three
values concurrently (the probe value, of one datatype, and two bin
boundary values of possibly a different type). The reason is that
it's stripping off whatever common prefix those strings have before
trying to form a numeric equivalent. While certainly
convert_string_to_scalar is pretty stupid in the face of non-ASCII
sort orders, the prefix-stripping is something I really don't want
to give up. So the design I sketched of considering each value
totally independently isn't good enough.
We could, perhaps, provide an API that lets an operator estimation
function replace convert_to_scalar in toto, but that seems like
you'd still end up duplicating code in many cases. Not sure about
how to find a happy medium.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, tomas.vondra@2ndquadrant.com
Subject: Re: user-defined numeric data types triggering ERROR: unsupported type
In-Reply-To: <24767.1506180446@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox