Feature #4418
improve/fix temp-table naming approach
0%
Related issues
History
#1 Updated by Greg Shah over 4 years ago
Ovidiu made changes to temp-table naming in #3324 which have been merged to trunk. However, there remains some issues with the approach (from #3324-5):
This is not a bullet-prof solution. There are still cases when this kind of name collisions can occur. We need to think of a better way to name the temp-tables and their interfaces. The old naming scheme was just a TT<n>. It was safe from this POV, but it was too cryptic.
The solution to add the procedure name, as Jaroslaw suggested, is not perfect: the name is generated while doing a cross-file analysis, when SHARED and tables with same structure are matched and a common interface name is selected for a set of compatible TEMP-TABLE definitions. I think it would be very strange to work with ttN_procA in procB file.
As a last resort, a temporary storage might be used to collect required data (as opposed to local annotations) and make the information available globally. However, I think there might be a way to solve this by using smarter annotations.
#2 Updated by Greg Shah over 4 years ago
- Related to Bug #3324: Incorrect handling of temp tables with the same name makes translated code non-compilable added
#3 Updated by Greg Shah over 4 years ago
As much as possible, I prefer for the temp-table names to retain the name given in the business logic definition. It may have business meaning and it certainly is most compatible with what the original developer intended.
With that said, there are definitely issues to be handled.
Another thing to consider is that having a stable conversion is quite important, as is incremental conversion.