[Firebird-devel] gbak and non-native ODS
All, Historically, GBAK has two features: 1) Ability to make a backup regardless of the database ODS. This can be used for downgrading, e.g. when the v2.5 GBAK attaches to the v3 engine and makes a backup that can be restored on version 2.5. And of course it can be used for upgrading too -- e.g. if a backup is done using the v3 GBAK and then restored into a v3 database. 2) Ability to restore any backup format into any database ODS. This feature is less known and supposedly used rarely. It was supposed to work mostly backwards -- e.g. if you have only a backup done with GBAK v3, you can use GBAK v3 to restore it into the v2.5 database. The "redundant" system tables/fields are just ignored in this case. If restoring forward, we have new system tables/fields that doesn't have corresponding data in the backup. Perhaps some of them may be cleverly initialized by the GBAK or by the VIO layer of the engine, but generally I'd say it's not guaranteed to work. But anyway, when Claudio had refactored GBAK in this regard, we seemed to agree to keep both these features. The problem is that the second feature seems broken in v3. RDB$AUTH_MAPPINGS appeared in ODS12 and can be partially restored into ODS11.2 but cannot be ignored when restoring to the older ODS. Backups containing RDB$DB_CREATORS and RDB$PACKAGES cannot be restored to ODS < 12. From one side, this looks like a broken feature. From another side, some newer data may be required for the database to remain workable. For example, I see no harm in skipping database creator's grants because they cannot be used by the older engine anyway. But packages are an essential part of the business logic. And some stored procedures may reference these packages. So creating the database without packages is likely to be pointless. And basically speaking, if some "newer" SQL-level feature was used in a database, it's unlikely to be down-gradable at all -- due to newer BLR verbs being unknown for the older engine version. IMO, we need to clearly decide whether we intend to support restore into the non-native ODS. Such a support requires noticeable efforts when extending GBAK with new system tables/fields. If we decide to drop it, then it's time for a major cleanup in the GBAK code. And let's also decide whether we do that in v4 only or in v3 too. If we keep it, let's decide what new tables can be ignored when restoring backwards and what ones are mandatory and thus should raise an error. We may also consider going half-way and limiting the backward restore to the one prior ODS version -- this will also simplifies the code a lot. Opinions, please. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6276) Conversion from WITH TIME ZONE to WITHOUT TIME ZONE types should drop the time zone instead of use the session time zone
05.04.2020 18:21, Adriano dos Santos Fernandes wrote: I also agree that the current behavior is much better. Me too. Let's keep it. On the other hand, we have others weird standard behaviors (CASE with string literals producing CHAR result, for example). Maybe we regret to did it in the standard way and would create it in a better way if it's doing today? Yes, I think so. Moreover, I see no problems to accept our mistake and re-work it to be more suitable for the real life. At least in the major release (v4 or the next one). And BTW, speaking about the make_desc_from_list() logic, IMO it was a big mistake (maybe ours, maybe standard's) to use it for *both* function argument lists (CASE/COALESCE/etc) and select-lists (UNION). I'm pretty sure this is wrong in the latter case. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6276) Conversion from WITH TIME ZONE to WITHOUT TIME ZONE types should drop the time zone instead of use the session time zone
On 05/04/2020 12:40, Mark Rotteveel wrote: > > If we do decide to follow the standard in this regard, then I would > recommend that we make an exception for the conversion applied by the > bind of TIME ZONE (or a specific time zone type) to LEGACY to convert > using the session time zone. > SET BIND just changes automatic described types. Types used by client messages (which generally but not always comes from the described types) works likes standard variables. So no, that would be a complete hack. And yes, this may be problematic for bind of TZ to WITHOUT-TZ types, although there are the extended types which makes this less worse. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6276) Conversion from WITH TIME ZONE to WITHOUT TIME ZONE types should drop the time zone instead of use the session time zone
On 05-04-2020 17:21, Adriano dos Santos Fernandes wrote: On 05/04/2020 05:22, Vlad Khorsun wrote: 05.04.2020 9:46, Mark Rotteveel wrote: Although I'm all for following the standard, I wonder of making this change is the right one to do. The current behaviour makes a lot of sense to me, and I'm not sure if the behaviour defined by the standard will make things understandable for users. I'm agree with Mark I also agree that the current behavior is much better. On the other hand, we have others weird standard behaviors (CASE with string literals producing CHAR result, for example). Maybe we regret to did it in the standard way and would create it in a better way if it's doing today? So I do not have a problem either way we decide. Would like to know Dmitry opinion. The problem we resolve with current solution is resolved in the standard way with cast(value at local as timestamp). If we do decide to follow the standard in this regard, then I would recommend that we make an exception for the conversion applied by the bind of TIME ZONE (or a specific time zone type) to LEGACY to convert using the session time zone. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6276) Conversion from WITH TIME ZONE to WITHOUT TIME ZONE types should drop the time zone instead of use the session time zone
On 05/04/2020 05:22, Vlad Khorsun wrote: > 05.04.2020 9:46, Mark Rotteveel wrote: >> Although I'm all for following the standard, I wonder of making this >> change is the right one to do. >> >> The current behaviour makes a lot of sense to me, and I'm not sure if >> the behaviour defined by the standard will make things understandable >> for users. > > I'm agree with Mark > I also agree that the current behavior is much better. On the other hand, we have others weird standard behaviors (CASE with string literals producing CHAR result, for example). Maybe we regret to did it in the standard way and would create it in a better way if it's doing today? So I do not have a problem either way we decide. Would like to know Dmitry opinion. The problem we resolve with current solution is resolved in the standard way with cast(value at local as timestamp). Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6276) Conversion from WITH TIME ZONE to WITHOUT TIME ZONE types should drop the time zone instead of use the session time zone
On 05/04/2020 07:46, Mark Rotteveel wrote: Although I'm all for following the standard, I wonder of making this change is the right one to do. The current behaviour makes a lot of sense to me, and I'm not sure if the behaviour defined by the standard will make things understandable for users. The main problem with much of this is that the 'standard' does not seem to actually understand the whole problem. MUCH of what is being discussed is the addition and subtraction of a fixed time offset. Much as happens in the browser headers currently. It has NOTHING to do with carrying a valid TIMEZONE around with the data and being able to handle simple local timezone time calculations which cross DST and other transitions relating to the full timezone rule set ... the second that a timezone identifier is dropped then one has lost vital information! ( The fact that the TZ database also drops validated rule changes prior to 1970 is another critical element here ... ) -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6276) Conversion from WITH TIME ZONE to WITHOUT TIME ZONE types should drop the time zone instead of use the session time zone
05.04.2020 9:46, Mark Rotteveel wrote: Although I'm all for following the standard, I wonder of making this change is the right one to do. The current behaviour makes a lot of sense to me, and I'm not sure if the behaviour defined by the standard will make things understandable for users. I'm agree with Mark Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
