Reflect on column type for writing formatting time

[calebhearth]

Use Postgres' preferred forms for date (no time) and time with and without
zone for writing those columns. Previously, these column types could not be
written, with the error:

pq: invalid input syntax for type time: "0001-01-01T17:00:00Z BC"

This change prevents that error.

From Postgresql docs:

The time-of-day types are time [ (p) ] without time zone and time [
(p) ] with time zone. time alone is equivalent to time without time
zone.

The date type represents only a day.

The other types, timestamp with and without time zone, were previously
functioning correctly.

[johto]

This doesn't seem like a good idea. Anything that requires looking at the inferred type for a parameter is going to work differently between prepared statements and single round-trip executions (in binary_parameters mode).

[calebhearth]

Anything that requires looking at the inferred type for a parameter is going to work differently between prepared statements and single round-trip executions (in binary_parameters mode).

It seems like a good portion of the types managed in encode are switching on the oid.Oid. Is there a better way to do this?

The current behavior is a confusing error message for any time or date type, so this feels like at least an improvement on that as encode will break in fewer cases. I'm happy to take a different approach if you have a suggestion.

[johto]

It seems like a good portion of the types managed in encode are switching on the oid.Oid.

That'd be exactly two types, and backwards compatibility with that poor decision is exactly why we had to implement the binary_parameters hack.

The current behavior is a confusing error message for any time or date type, so this feels like at least an improvement on that as encode will break in fewer cases.

date works just fine. This is only an issue with the time type.

I'm happy to take a different approach if you have a suggestion.

A wrapper for time.Time which implements Valuer sounds like the best option here. Not sure what to call it, though; pq.Time is not almost certainly not a good idea since it's too easy to confuse with the wide range of functionality supported by time.Time.

[cbandy]

A wrapper for time.Time which implements Valuer sounds like the best option here. Not sure what to call it, though; pq.Time is not almost certainly not a good idea since it's too easy to confuse with the wide range of functionality supported by time.Time.

I called it pq.Clock in #344.

[calebhearth]

Not a bad name. Could also use pg's names: pq.TimeWithTimeZone, pq.TimeWithoutTimeZone

[calebhearth]

@johto Does @cbandy's solution in #344 work for you?

[johto]

@johto Does @cbandy's solution in #344 work for you?

I had another peek and I think we could probably start by committing the pq.Clock part. Have you tested that it works for your case?