Message-ID: <gh-pgjdbc-pgjdbc-1225-c516510068@github.com>
From: "bokken (@bokken)" <noreply+bokken@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Tue, 30 Jul 2019 17:12:00 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #1225: Java 8 Time Support for Postgres Arrays
In-Reply-To: <gh-pgjdbc-pgjdbc-1225@github.com>
References: <gh-pgjdbc-pgjdbc-1225@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: bokken
X-GitHub-Comment-Id: 516510068
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 1225
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/1225#issuecomment-516510068
Content-Type: text/plain; charset=utf-8

I think we could relatively easily allow consumer to override default array
type handling once the PR for reworking array decoding is merged.

On Tue, Jul 30, 2019 at 9:16 AM Dave Cramer <notifications@github.com>
wrote:

> you'd probably be surprised to know that timestamp with timezone doesn't
> store the timezone either then.
>
> In PostgreSQL -- yes, I know.
>
> Right, I missed the fact the issue is broader than just timestamp[].
> I was not as much concerned about timestamptz[] being mapped to
> java.sql.Timestamp[] because in timestamptz case all I need is point in
> time. So this mapping at least does not lose information.
> https://github.com/prestosql/presto/blob/c39358eee752eac13959fd05dc5427502cf03b33/presto-postgresql/src/main/java/io/prestosql/plugin/postgresql/PostgreSqlClient.java#L355-L357
>
> (Or course java.time.Instant would be more appropriate)
>
> For date[], mapping to java.sql.Date[] loses information in one edge case
> only (DATE '2011-12-30' and Pacific/Apia zone). Of course, it's still
> desirable to get the date[] data as java.time.LocalDate[].
> Can you elaborate on why this one edge case fails
>
> (Let me explain my point of view. I am concerned mostly about losing
> information and not about convenience, because in Presto use-cases, not
> losing information is all we need. Even accessing String would be enough.
> Others, are probably more interested in getting java.time. classes because
> in application code there is usually more code that interacts with JDBC in
> some way.)
>
> Sadly the whole date/time/timestamp thing with java and JDBC is beyond
> repair. We have to chose to be opinionated here. At the moment I'm not sure
> of the "best" opinion. I'm going to confer with the npgsql guys to see what
> their driver does to get some level of consistency
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/pgjdbc/pgjdbc/issues/1225?email_source=notifications&email_token=AAW3U3LOBA5R5MSNNFFKJHDQCBEKHA5CNFSM4FG5ZJFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3EDTYI#issuecomment-516438497>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAW3U3PVECBLJ6JNV2QTEP3QCBEKHANCNFSM4FG5ZJFA>
> .
>