Issue Details (XML | Word | Printable)

Key: CORE-5853
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Adriano dos Santos Fernandes
Reporter: Adriano dos Santos Fernandes
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

Forward-compatible expressions LOCALTIME and LOCALTIMESTAMP

Created: 20/Jun/18 03:58 PM   Updated: 21/Sep/18 05:15 PM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 3.0.4, 2.5.9

QA Status: Done with caveats
Test Details:
Empty code remains for 4.0 section in .fbt: waiting for merging this new feature in master.

 Description  « Hide
In version 4.0, Firebird will support time zones.

Within this support will come an incompatibility with previous versions' `CURRENT_TIME` and `CURRENT_TIMESTAMP` expressions.

In v4, `CURRENT_TIME` and `CURRENT_TIMESTAMP` will respectively return expressions of data type `TIME WITH TIME ZONE` and `TIMESTAMP WITH TIME ZONE`.

To make your queries and database code compatible with future versions, from v3.0.4 you can instead use `LOCALTIME` and `LOCALTIMESTAMP`. In v3, these `LOCAL*` expressions will work indenticaly to their correspondents `CURRENT_*` expressions.

In v4, `LOCAL*` expressions will continue to work identically as now, but the `CURRENT_*` expressions will change.

You should not start using `LOCALTIME` and `LOCALTIMESTAMP` if your database may be downgraded to v3.0.3 or another version, as the old versions will not recognize the new expressions.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 20/Jun/18 04:07 PM

For consistency, would "LOCAL_", instead of "LOCAL" be a more appropriate prefix?

IMO it would align with the existing "CURRENT_".

Karol Bieniaszewski added a comment - 20/Jun/18 04:25 PM
Why not CURRENT_TIME_TZ and CURRENT_TIMESTAMP_TZ for new timezone support
instead braking old working codes?

Adriano dos Santos Fernandes added a comment - 20/Jun/18 05:32 PM
SQL standard defined as LOCALTIME and LOCALTIMESTAMP.

Nick added a comment - 21/Jun/18 06:10 AM
Maybe we can create new sql dialect for sql-standard?
And another one for legacy?
And another one, say it trunk dialect, without legacy and sql-standard brain-breaking stuff? :)

Maybe we can have a plugin for working with dialects? :)

Simonov Denis added a comment - 22/Jul/18 11:19 AM
Will there be a backport in 2.5.x? Many developers have not yet migrated to 3.0 and are waiting for release 4.0. If I understand correctly with release 4.0, support 2.5 will stop. Give them a chance to migrate to 4.0 without intermediate migrations 2.5 -> 3.0 -> 4.0.

Adriano dos Santos Fernandes added a comment - 25/Jul/18 04:11 PM
Backported to 2.5.9.

Pavel Zotov added a comment - 31/Jul/18 11:19 AM
What is the proper syntax in 4.0 for these new keywords ( `LOCALTIME` and `LOCALTIMESTAMP`) ?
The following script:

set list on;
set echo on;

show version;

select current_time, current_timestamp from rdb$database;

select localtime from rdb$database;

select localtimestamp from rdb$database;

-- works OK on and, but on WI-T4.0.0.1142 i get:

select current_time, current_timestamp from rdb$database;

CURRENT_TIME 14:18:16.0000
CURRENT_TIMESTAMP 2018-07-31 14:18:16.3690

select localtime from rdb$database;
Statement failed, SQLSTATE = 42S22
Dynamic SQL Error
-SQL error code = -206
-Column unknown
-At line 1, column 8
At line 7 in file c5853.sql

select localtimestamp from rdb$database;
Statement failed, SQLSTATE = 42S22
Dynamic SQL Error
-SQL error code = -206
-Column unknown
-At line 1, column 8
At line 9 in file c5853.sql

Firebird/Windows/Intel/i386 (access method), version "WI-T4.0.0.1142 Firebird 4.0 Alpha 1"
Firebird/Windows/Intel/i386 (remote server), version "WI-T4.0.0.1142 Firebird 4.0 Alpha 1/tcp (csprog)/P16"
Firebird/Windows/Intel/i386 (remote interface), version "WI-T4.0.0.1142 Firebird 4.0 Alpha 1/tcp (csprog)/P16"
on disk structure version 13.0

Adriano dos Santos Fernandes added a comment - 31/Jul/18 12:03 PM
The changes are not merged in master yet.

Dmitry Yemanov added a comment - 21/Sep/18 06:34 AM
I'd suggest making LOCALTIME / LOCALTIMESTAMP non-reserved in v2.5 / v3.0, regardless of the standard requirements. I'm afraid making existing objects with the same names unusable is too radical for a point release. This has already appeared in our test suite (test bugs.core_4470 contains a packaged function named LOCALTIME and now throws a parsing error), so the issue is not purely theoretical.

Adriano dos Santos Fernandes added a comment - 21/Sep/18 03:24 PM
LOCALTIME / LOCALTIMESTAMP (without the precision) are very equivalent to a uncontexted column access and with the precision syntax are identical to a function call.

So how can we make them non-reserved?

It's already in keyword_or_column, but non_reserved_word will not work for them.

Dmitry Yemanov added a comment - 21/Sep/18 05:15 PM
I missed that point, sorry. Agreed it's not possible.