UDTF mit optionalen Input-Parametern

[Fuerchau]

Das mit den Defaults für Parameter wurde bereits oben erwähnt und manche OO-Sprachen kennen das auch.
Ich habe ja nur gesagt, dass man Funktionen/Prozeduren mit allen Parametern auch mit individuellen Defaults(=Konstanten, NULL) aufrufen kann.
Bei solchen Konstrukten (Defaults/Überladungen) bedarf es schon genauer und guter Dokumentation, damit man nicht auf die Nase fällt.
Seit Einführung der globalen SQl-Variablen (V7R1?) falle ich leider immer wieder auf die Nase, da der Compiler mir nur noch in seltenen Fällen Tippfehler als Fehler rauswirft und ich mich erst zur Laufzeit Frage, warum was nicht läuft.
Vielleicht kann man das ja zur Compilezeit irgendwie als Warnung oder mit Heruntersetzen der Bewertung anpassen damit der Compiler Fehler wieder meldet.

[BenderD]

... ich denke, dass man da noch etwas tiefer einsteigen muss:
Überladung und optionale Parameter sind zwei verschiedene Dinge, wobei Überladung der stärkere Mechanismus ist, weil bei der Verwenung bereits zur Compiletime geprüft wird und die zu übergebenden Parameter keiner Anordnungsbedingung unterliegen.
Namensparameter sind zwar sehr flexibel, was aber gerade die Prüfbarkeit zur Compilezeit einschränkt; zudem muss der Verwender mehr Wissen über die innere Implementierung haben.

Was das ursprüngliche Problem angeht (Überladung einer external (RPG) UDTF) ist es wohl am einfachsten (und damit auch am besten), die Überladung in der RPG Implementierung mit abzubilden und mehrere RPG Aufrufpunkte zu haben (1 : 1 zu den Überladungen). Hier bietet sich dann eher ein SRVPGM an. Die Verzweigung kann dann wieder in einer Implementierung münden, die den Hauptteil der Logik einthält.

D*B

[dschroeder]

Vielen Dank für alle Antworten. Ich habe viel neues erfahren. Mein eigentliches Problem war ja die Fragestellung, weshalb die im RPG erwarteten optionalen Parameter nicht rüberkamen. Auf die simple Idee, im SQL Null anzugeben, bin ich ich nicht gekommen.
Die Sache mit den benannten Parametern war mir ebenfalls nicht bewusst. Ich habe die Syntax im SQL in den neuen mitgelieferten Funktionen zwar schon ein paar Mal gesehen, aber mir war eigentlich nicht richtig klar, dass damit eine Parameterbenennung realisiert wird. Danke auch für diesen Ansatz.

Ich wünsche allen einen guten Start in die neue Woche.
Dieter

[andreaspr@aon.at]

Und falls wer meint, dass zum Compile-Zeitpunkt keine Prüfung stattfindet, bitte es einfach mal ausprobieren.
Der Fehler ist dann nämlich:

The CALL statement or function invocation includes named argument &1 which does not exist for routine &2 in schema &3.

[BenderD]

... zwischen nix prüfen und wenig prüfen können, gibt es wesentliche Unterschiede - nur so am Rande, der Präzision halber, erwähnt.

[Fuerchau]

Ich meinte ja auch die Nichtprüfung von Spaltennamen in Select und Where-Klauseln, die nun leider erst zur Laufzeit passieren, da alle nicht gefundenen Namen, die nicht explizit benötigt werden, für globale Variablen gehalten werden. Und das schlägt erst zurLaufzeit an. Da reicht schon mal das Vergessen eines Doppelpunktes.