Introduce type attributes in yml

[tiii]

Enabling generation of view creation sql, resulting in valid examples in the readme.

No more CREATE OR REPLACE (MATERIALIZED) VIEW view_name AS in the views sql parameters.

I guess there should be an equivalent for functions?

With this we can strip out the check on the database, since we use CREATE/DROP IF EXISTS anyways..

[fqxp]

Valid idea, but I think we need to discuss how to do this for functions before merging this. Otherwise we'd have annoying inconsistencies in definition files where we need CREATE statements for functions but not for views.

Problem is that functions, other than views, can be overloaded and therefore there might exist multiple functions with the same name, distinguishable only by full signature.

One idea to solve this was to make viewr very generic and make it necessary to provide CREATE statements as well as DROP statements, and possibly making viewr database object type-agnostic. This way, we wouldn’t need signature definitions in YAML to be able to build DROP FUNCTION statements because viewr doesn’t need to build DROP statements anyway. On the other hand, you'd need a lot of repetetion because for views, the DROP statements are always the same.

Another idea, which would be following your approach, is to include function signature definitions in the YAML file and build CREATE/DROP statements from these. Just to get an idea, this might look like this:

name: smoke
dependencies:
  - materials
parameters:
  - IN blunt INTEGER
  - OUT cough VARCHAR

I’m more fond of the latter idea because this makes the whole database object handling more explicit and provides for more possibilities in the future. We should only make it more generic when applicable later.

Let’s discuss this here, @tiii, @Tranquility and @maiwald!