Why to remove the Array type ? , I see that Postgresql still provides it https://www.postgresql.org/docs/current/arrays.html
On Wed, Apr 22, 2020 at 2:49 PM Pavel Cisar <pci...@ibphoenix.cz> wrote: > Hi all, > > I'm writing new Python driver built using new FB3 API (mainly to get > support for new features not available through old API). I was surprised > that ARRAY type support in new API is incomplete and thus it's not > possible to handle this data type in drivers/applications. Specifically, > the API provides getSlice & putSlice methods on IAttachment, but there > isn't any equivalent for very important isc_array_lookup_bounds function > (isc_array_lookup_desc and isc_array_set_desc are also missing, but they > are not important for driver developers). > > Alex explained to me, that array support is not functional in new API, > because core developers are considering to deprecate & remove ARRAY type > support from future Firebird versions. And because the final decision > was not made yet, the arrays support in new API get stuck in incomplete > state. > > Personally, I have no problem with deprecation of the ARRAY type, as > this type is mostly not used (if at all) by Firebird users. Also, I > understand the reasoning for missing methods that would pollute the > interfaces with methods that would become eventually obsolete. However, > I'm really stunned how this issue was handled. > > While it's ok to provide only new API for new features (like scrollable > cursors), the NEW API SHOULD support all old Firebird features present > in given version and available through old API. And ARRAY type is such a > feature. Although it's probably not used much by Firebird users, it's > still used in example EMPLOYEE database that's used a lot in books, > articles etc., and support for it is available to end users via some > drivers (like FDB Python driver) for many years. So it's definitely > POSSIBLE, that users will run into situations when lack of ARRAY support > will be at least awkward (missing output), if not straight fatal. > > Argument that one could always use old API to access ARRAYs will not > stand, because some new features are not available through it, and they > could not be used together. Users should NOT be forced to choose between > two API's with distinct features, at least one should be the superset > (preferably the new one). > > Also, if ARRAY type should be ever removed from Firebird, it should be > done via proper deprecation process (that also includes creation of new > example database without it). Hence I consider the lack of (at least) > isc_array_lookup_bounds equivalent in new API as a serious BUG, that > should be fixed in Firebird 3 & 4. As driver developer I would really > appreciate if it would be fixed for 3.0.6 due in June. > > While ARRAY support is the pressing matter here, there are other old API > functions that does not have new API replacements (for example > isc_blob_lookup_desc, and many others). I think that it's the good time > to compare old and new API's, and create a document that will contain > table listing the Old API functions with their New API counterparts, or > explanation why it was decided to not provide such equivalent in new > API. Such document should be first discussed here (so we could decide > whether to fix more new API bugs asap), and then become a part of > Firebird documentation set (as driver developer, I was really surprised > that such document does not exists yet, as it's invaluable for porting > from old to new API). > > best regards > Pavel Cisar > > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel >
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
