Fix failure of insertion of timestamp on JDBC

[ShanBai6]

Fix the timestamp issue #7747 and Add/Extend original test to cover the timestamp type as well.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions.

[arhimondr]

It does nothing

/**
     * Time unit representing one thousandth of a second
     */
    MILLISECONDS {
        public long toNanos(long d)   { return x(d, C2/C0, MAX/(C2/C0)); }
        public long toMicros(long d)  { return x(d, C2/C1, MAX/(C2/C1)); }
        public long toMillis(long d)  { return d; }
        public long toSeconds(long d) { return d/(C3/C2); }
        public long toMinutes(long d) { return d/(C4/C2); }
        public long toHours(long d)   { return d/(C5/C2); }
        public long toDays(long d)    { return d/(C6/C2); }
        public long convert(long d, TimeUnit u) { return u.toMillis(d); }
        int excessNanos(long d, long m) { return 0; }
    },

[findepi]

Has this been addressed?

[ShanBai6]

This is the same portion of code as below, we decide to keep it as this for now.

[arhimondr]

try to use the following method

statement.setTimestamp(next(), new Timestamp(utcMillis), Calendar.getInstance(/*force time zone to be UTC*/TimeZone.getTimeZone("UTC"), /*force calendar to be Gregorian*/ ENGLISH);)

[findepi]

AFAIK, postgres doesn't follow standard with respect to timestamp semantics. Did you check that?
In anyway, make sure value read from postgres is the same as value written earlier.

[ShanBai6]

This will be done in a separate patch after further discussion.

[arhimondr]

Name test is too generic. Call it test_describe_table_all_types.

[arhimondr]

Prefix column names with c_ instead of test_. For instance c_varchar_255, c_varchar_15, c_timestamp, etc.

[arhimondr]

Do "all types" test as it is done for describe statement.

[ShanBai6]

Describe test could be done for all types, while the insertion has to wait for later as some data types still have issues.

[arhimondr]

Same comment about column names

[arhimondr]

ditto

[arhimondr]

ditto

[findepi]

AFAIK, postgres doesn't follow standard with respect to timestamp semantics. Did you check that?
In anyway, make sure value read from postgres is the same as value written earlier.

[findepi]

None of the tests exercises CTAS and #7747 mentions CTAS.

[arhimondr]

LGTM

[kubum]

Hi @arhimondr! It looks like an interesting PR, if I fix the conflicts would you be able to help and a look again into merging it? Thanks!

[findepi]

There is no correct and portable way for handling timestamps, especially when legacy_timestamp=false session toggle is set.
@kubum #12151 is a refactor that provides basis for handling the conversions in database-specific way where appropriate.

[kubum]

Thank you for the quick response @findepi!