pg driver: fixed %dt with interval

[Mikulas]

Nextras\Dbal\QueryException: ERROR: invalid input syntax for type interval: "2015-10-28 11:22:42"
LINE 1: SELECT Now() <= '2015-10-28 11:22:42' + (INTERVAL '2 DAYS')

[Mikulas]

This should not introduce any bc break. Pg allows type cast nesting and timestamptz does not loose data

select '2015-11-27 11:49:36.002+02'::timestamptz::timestamptz 2015-11-27 10:49:36.002+01

[milo]

Opened Tester issue nette/tester#268.

[hrach]

SELECT Now() <= %dt::timestamptz + (INTERVAL '2 DAYS')

doesn't work?

[hrach]

I'm not sure, if passing parameters should automatically cast them. We may do the same for integers, booleans, ...

[Mikulas]

Not quite, this type cast does not loose any precision and is in fact the cast postgres would love to do internally, but does not have enough information about. The string could be a generic (even composite) type, but orm knows it's a simple ymd his format.

The cast is not strictly required in orm, but it never breaks anything and is very convenient.

[hrach]

Not quite, this type cast does not loose any precision

I do not claim it does.

but orm knows it's a simple ymd his format.

but we are in Dbal, not in ORM layer. Since Nextras ORM doesn't allow you to use interval expression and you always have to write it manually using dbal's interface, I still don't see the usecase even for Orm.

[Mikulas]

but we are in Dbal, not in ORM layer

I misspoke, dbal indeed, but the argument holds.

Nextras ORM doesn't allow you to use interval expression

Not a requirement, interval is simply the case I chose to put in test as it's afaik the most common case. The cast is required anywhere pg can't type cast it automatically.

Is there any negative effect of this change?

[hrach]

At least inconsitence. Also sql clutter.

We may do the same for integers, booleans

@JanTvrdik what do you think?

[Mikulas]

Fair point. I would obviously like to see this merged, but it's up to you.

Int and bool typecasts are either not required as dbal sends the correct type (eg %d => 1 or %b => false) or cannot be cast automatically by dbal (%s with 'false' => 'false'::bool => false)

[hrach]

Could you provide your real-worl usecase, when you discovered such drawback?

[Mikulas]

Interval, complex query but the test case is the minimal version of that already. It would also be required for any function or operator that is defined for both string and a timestamp[tz]/date[time]/time.

[Mikulas]

Another way of thinking about it is that orm is currently relying on automatic type cast.

SELECT pg_typeof(timestamptz('2015-01-01 10:10:10')); -- timestamp with time zone SELECT pg_typeof('2015-01-01 10:10:10'); -- unknown 

[hrach]

change this to timestamp and I will merge this.

[Mikulas]

That was original implementation. I choose to rebase it with this simply for it's semantic value: I interpret tz as the timezone is known (in contrast to timestamp, which might indicate a time from application in unknown tz).

Without the timezone specified in the format string, those are all equivalent (as in interchangeable)

select '2015-01-01 16:00:00'::timestamp; select '2015-01-01 16:00:00'::timestamptz::timestamp; select '2015-01-01 16:00:00'::timestamptz; select '2015-01-01 16:00:00'::timestamp::timestamptz;

but I wouldn't mind timestamp either; is there a reason you requested timestamp?

[Mikulas]

I'm ok if this does not get merged, but we will need Mikulas@d9c9245 anyway (that's why #16 is broken)

[hrach]

Sorry, I forget to fully think it out. I'm definitelly against timestampttz for both cases. If the behavior is the same as you pointed out, it doesn't make sence at all.

[hrach]

Oh no, seems that you still didn't understand the dbal approach :)) Please, keep timestamptz for %dt :)

[Mikulas]

Sorry, that makes no sense (to me, anyway). I rebased it, though.

edit: misclick

[hrach]

great! thanks!