Sorry to do nit picking here, but there is one last thing I want to bring up once more.

Usage of temporary in variable declarations. I dont care if its used or not if a table has TableType = temporary but if its used, it should be done on all variable declarations, in this PR its not

IMHO its just inconsistent coding.

Sorry to do nit picking here, but there is one last thing I want to bring up once more.

Usage of temporary in variable declarations. I dont care if its used or not if a table has TableType = temporary but if its used, it should be done on all variable declarations, in this PR its not

IMHO its just inconsistent coding.

As long as the record is passed via var, temp or not doesn't matter anyway. I added it only to the fascade to make it clear in the Module Fascade Documentation. @JesperSchulz, @darjoo how should I proceed?

. I dont care if its used or not if a table has TableType = temporary

I don't have a definite answer here. I'm all for consistency, and I definitely prefer to see in the parameter list and parameter name, when a record is temporary - it just makes it easier to understand what's going on, without having to peek on the actual table object to see if it happens to be a temporary one.

Temporary on object level was added a small handful years ago to allow us to have a table object which won't result in breaking schema changes, when changed. We for instance had buffer tables in the system, which only ever were used as temporary tables, but which we couldn't change as the schema was synchronized. That was annoying and hence the temp property was added to help the compiler understand what kind of table we're dealing with here.

Long story short: In my opinion, you should "double specify" temporary. The property simply ensures, that you won't ever store the table in the DB.

However, we do not have firm rules around that (yet). The property was introduced quietly and we never got around to create rules for it.

But I agree with Stefan, that we at least must be consistent - if not everywhere, then at least in the module. So go for being explicit about the temp property in the procedure parameters and parameter names.

. I dont care if its used or not if a table has TableType = temporary

I don't have a definite answer here. I'm all for consistency, and I definitely prefer to see in the parameter list and parameter name, when a record is temporary - it just makes it easier to understand what's going on, without having to peek on the actual table object to see if it happens to be a temporary one.

Temporary on object level was added a small handful years ago to allow us to have a table object which won't result in breaking schema changes, when changed. We for instance had buffer tables in the system, which only ever were used as temporary tables, but which we couldn't change as the schema was synchronized. That was annoying and hence the temp property was added to help the compiler understand what kind of table we're dealing with here.

Long story short: In my opinion, you should "double specify" temporary. The property simply ensures, that you won't ever store the table in the DB.

However, we do not have firm rules around that (yet). The property was introduced quietly and we never got around to create rules for it.

But I agree with Stefan, that we at least must be consistent - if not everywhere, then at least in the module. So go for being explicit about the temp property in the procedure parameters and parameter names.

Done.