čt 6. 1. 2022 v 20:03 odesílatel Joel Jacobson <joel@compiler.org> napsal:
On Thu, Jan 6, 2022, at 19:03, Pavel Stehule wrote:
> The possibility to define a label dynamically is a better solution (not by some buildin keyword),
> because it allows some possibility for the end user to define what he prefers.
I'm trying to understand why you think a user-defined notation is desirable,
why it wouldn't be better if the SQL standard would endorse a notation,
so we could all write code in the same way, avoiding ugly GUCs or PRAGMAs altogether?
But there is nothing similar in standard. Standard doesn't specify any column or table or label names in the custom area.
The ADA language, an PL/SQL origin, and the PL/pgSQL origin has not nothing similar too. Moreover it (ADA language) was designed as a safe, very verbose language without implicit conventions.
I think we have different positions, because we see different usage, based on, probably, a different programming style. I can understand the request for special common notation for access for routine parameters. But the "in" keyword for this case is not good, and I really think it is better to give some freedom to the user to choose their own label, if we don't know the best one.
If "in." would work, due to "in" being a reserved SQL keyword,
don't you think the benefits of a SQL standardized solution would outweigh our
personal preferences on what word each one of us prefer?
I know that "in" is a reserved word in SQL, but I have not any knowledge of it being used as alias in SQL functions or in SQL/PSM functions.
