Re: BUG #18780: Bindings types are lost for complex queries - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: BUG #18780: Bindings types are lost for complex queries
Date
Msg-id CAKFQuwauor0qYsPaB1CEu5atYu6H1y1ibcVA0VtgxkLKVyDXig@mail.gmail.com
Whole thread Raw
In response to BUG #18780: Bindings types are lost for complex queries  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #18780: Bindings types are lost for complex queries
Re: BUG #18780: Bindings types are lost for complex queries
List pgsql-bugs
On Sunday, January 19, 2025, PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:

Bug reference:      18780
Logged by:          Viktr
Email address:      vik@notexi.st
PostgreSQL version: 17.2
Operating system:   Linux d2c635331de7 6.10.14-linuxkit #1 SMP PREEMPT
Description:       

Hi there,

Actual discussion is here: https://github.com/pgjdbc/pgjdbc/issues/3482
In brief: I do understand that "select 1 as one, 2 as two, 3 as three" might
have lack of type info. But I suppose, in case these values are used in the
assignment, the type could be taken from the corresponding column type. Like
for "insert into sometable(one, two, three) select 1 as one, 2 as two, 3 as
three" it is obvious that types should match.


A bug report should be self-contained.  Only pointing to a 40 message long thread isn’t helping get the bug (well, feature) fixed.

The crux of that thread is your driver is sending along a text data typed value because it cannot decide whether timestamp or timestamptz is needed.  Implicitly casting text to something else isn’t going to happen.

This falls into a feature request, one that comes up from time-to-time, and doesn’t ever seem to meet anyone’s benefit/cost threshold for working on; or at least get pushed over the edge.

The underlying feature, I think, is you want the parse to be able to say “let the server decide the type” and the server reply with type info for unspecified parameters.  Or maybe accept the pseudo-type “unknown” at the API level.  In any case a thread to discuss a patch for such a change and how JDBC would leverage it to solve this problem would be the next step.  Searching the mailing lists for existing discussions may yield fruit too though I don;t know for certain.

David J.

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18781: pg group gy The number of returned data bars in a field is inconsistent
Next
From: Tom Lane
Date:
Subject: Re: BUG #18780: Bindings types are lost for complex queries