On 01/05/2018 07:45, Vlad Khorsun wrote:
> 
>> - Compatibility:
>>
>> It was been created four new datatypes:
>> - TIME WITH TIME ZONE
>> - TIMESTAMP WITH TIME ZONE
>> - TIME WITHOUT TIME ZONE
>> - TIMESTAMP WITHOUT TIME ZONE
>>
>> The old types (TIME and TIMESTAMP) resolves to the "WITHOUT" version.
>>
>> So the first compatibility problem is when client selects the types WITH
>> TIME ZONE.
> 
>   I suppose you speak about old clients here, which have no support for
> new datatypes, correct ?
> 

Yes.


>> It can be resolved with same solution as DECFLOAT (SET DECFLOAT BIND
>> ...):
>> - SET TIME ZONE BIND { NATIVE | LEGACY } (better suggestion welcome)
> 
>   What should be used by default ?

It should match functionality and default of SET DECFLOAT, i.e., be
default the new behavior (describe types with TZ as types with TZ).

Problematic clients will use the legacy option.


> How conversion "TIME WITH TIME ZONE"
> to "TIME" will happen - will it just ignore time zone information, or
> will it change value of time (accouting time zone) returned to the client ?
> 

Let's say first about TIMESTAMP.

There is session time zone. Session time zone is currently defined as
default with the server time zone.

We may think that's not ideal and session time zone should be defined
with the client time zone initially. But that per se is not correctly
too. In web applications the middle-ware (database client) does not
represent the user's session too. And it may be very problematic for
compatibility.

So conversion from TIMESTAMP WITH TIMEZONE value (with TZ equal to the
session timezone) to TIMESTAMP (WITHOUT TIME ZONE) will just "truncate"
the timezone and have no compatibility problems.

If the value's TZ is different than the session time zone, it will
translate the value from TZ to the session time zone.


>> Also there are new expressions, LOCALTIME and LOCALTIMESTAMP with
>> functionality equivalent to the Firebird's CURRENT_TIME and
>> CURRENT_TIMESTAMP.
>>
>> But standard CURRENT_TIME and CURRENT_TIMESTAMP  works different than
>> Firebird, as they returns the "WITH TIME ZONE" types.
>>
>> Tweaking CURRENT_TIME/CURRENT_TIMESTAMP for compatibility is problematic.
> 
>   How it is different from problem above ?
> 

Do not understand what you mean.


>> It may be in stored routines or in ad-hoc queries. Stored routines are
>> sometimes "recompiled" by tools, i.e., recreated from sources.
> 
>   What if store new datatype at BLR level but return datatype according to
> the SET TIME ZONE BIND rule ?
> 

SET TIME ZONE BIND should be valid only for describe query binds.
Internal operations should not rely on it.


>> If there is attachment option that changes the behavior of DDL commands,
>> users will soon have problems when sometime it will be used and sometime
>> it will not.
> 
>   Agree, DPB is not good for such things.
> 
>> Also database config option for this will create problems as each client
>> (submitting queries) will work different.
> 
>   Explain, please. It seems for me that SET TIME ZONE BIND statement with
> default values set at database level (via config) could resolve all issues.
> Am i wrong ?
> 

Users (devs) will need another thing to think and will always need to
issue a SET TIME ZONE BIND for v4, as they will not known what database
admin configured or if database admin will change it and broke its
application.

On the other hand, without config option the application developer will
known behavior after known it's connected to v4.

Sure, old and unmaintained applications may have a problem, but this
type of usage should better maintain every component (database server)
as "homologated".


>> So what I propose here is a migration path that does not breaks the new
>> feature nor the old code if users implement the migration correct.
>>
>> I propose to add LOCALTIME/LOCALTIMESTAMP to next Firebird 3 version as
>> synonym for its CURRENT_TIME/CURRENT_TIMESTAMP.
>>
>> So before migrate to v4, users can adjust their code using Firebird 3
>> and once upgraded there will be no problems.
> 
>   I'd add it into 2.5.9 also, as many users will upgrade from per-v3
> versions.
> 

Could be.


>   BTW, we could (should ?) add more such forward-compatibility features
> into
> last release of 2.5
> 

I think it's always preferred to do small tweaks in old versions than to
compromise Firebird's future with hacks for compatibility usage.

It's very difficult to update a database server when stored database
code or application queries works different in the old and new version.
Requiring a first minor version update for post code adjustments is
generally not a problem.


Adriano

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to