Commented by: Saulius Vabalas (svabalas)

Any chance this requests can be scheduled for v3.0? Seems like there are multiple Duplicate requests reported, but nothing is happening since year 2003. Having arrays in SP's and triggers would save a lot time for developers using FB avoiding temporary tables or ugly code for simple coding tasks.

Commented by: @dyemanov

I doubt I have any positive answer for you. So far virtually nobody used arrays in production and its support in connectivity toolset is very limited (if exists at all). The original implementation by Borland contains some bugs that were never addressed, and I'm afraid new development for the past years didn't pay enough attention to that code either. You could see people even requesting to drop this (basically dead) code and forget about it and I do understand the reasoning behind. Many years ago I tried to estimate the efforts required to have it supported in PSQL but gave up. A lot of work for a very small benefit. This is why it always had the lowest priority among other requested features. You know the roadmap priorities for v3.0 and I hardly see this feature fitting them. Personally, I'd rather spend time on declared local temporary tables (feature from the SQL standard) that are defined in the PSQL module, invisible outside that module, die once getting out of the appropriate scope and processed mostly in memory.

Going slightly off-topic, I have a feeling that once some procedure starts to urgently need arrays / linked lists / queues / stacks / hash tables instead of tables, it should be rewritten in the non-SQL language :-) Firebird v3.0 offers support for external procedures written in any language and they may run SQL callback statements inside their execution context, so it gets perfectly doable.

Perhaps we could better discuss your particular needs if you'd share why temporary tables are ugly for your design?

Commented by: Saulius Vabalas (svabalas)

Array functionality in our case is needed only in PSQL area when some financial calculations based on months and other variables have to be calculated in SP's and when storing such data on temp tables produces too big overhead on performance due to accumulated old record versions. There is no need for arrays on table field level what so ever. So Your PSQL local temp in-memory table approach with execution lifetime approach seems like a good way to eliminate the need for arrays for ever. What's the likelihood of pushing this new feature request into v3.0?