Calling packaged routine names with keywords without double quotes

[Adriano dos Santos Fernandes]

Hi!

I propose allowing to call *packaged* procedures and functions using
also keywords (i.e., something like keyword_or_column using better name).

This would be mostly to allow creating system packaged routines with
keyword names and call them without double quotes. For example, in
RDB$BLOB_UTIL it's difficult to create names that do not clash with
keywords.

As a side effect it will allow user to create packaged routines with
keywords as usual (using double quotes), but calling them without double
quotes too.

In test this didn't introduce any parser ambiguities in the language.


Adriano

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 22.10.2022 16:06:
> In test this didn't introduce any parser ambiguities in the language.

Did you try how it works with non-ascii identifiers or containing special
symbols like spaces?

--
WBR, SD.

[Mark Rotteveel]

I don't see why such an exception should be added. Reserved words are
reserved words and need to be quoted. Such odd exceptions to the rules
can cause issues in other tools that need to parse queries, and could -
potentially - cause issues when adding new SQL features in the future.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

The proposal by Adriano is to allow reserved words as procedures and
function names in packages without requiring quotes when calling them,
not to do away with quoted identifiers entirely.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Mark Rotteveel wrote 22.10.2022 16:40:
>>    Did you try how it works with non-ascii identifiers or containing special
>> symbols like spaces?
>
> The proposal by Adriano is to allow reserved words as procedures and function
> names in packages without requiring quotes when calling them, not to do away
> with quoted identifiers entirely.

Yes, "mostly". But whatever people are allowed to try they will try.

--
WBR, SD.

[Mark Rotteveel]

Also, consider the confusion this yields for statements in a package
body calling other functions or procedures declared in that package body
(which would require quoting(!)).

For consistency sake, I don't like it.

Mark
--
Mark Rotteveel

[Adriano dos Santos Fernandes]

On 22/10/2022 11:43, Mark Rotteveel wrote:
>>
>> I don't see why such an exception should be added. Reserved words are
>> reserved words and need to be quoted. Such odd exceptions to the rules
>> can cause issues in other tools that need to parse queries,

That's another issue. We're in the very bad situation that drivers do
things that makes core evolution difficult.

>> and could - potentially - cause issues when adding new SQL features in the future.
>

Any new keyword, per definition, may break existing code.

The fact to limit the usage only for packaged routines is to limit
possibility of problems when features using that keywords has some changes.

> Also, consider the confusion this yields for statements in a package
> body calling other functions or procedures declared in that package body
> (which would require quoting(!)).
>
> For consistency sake, I don't like it.
>

Since the definition of the routines still requires the double quotes,
it's not a big deal.

It's why I called it a side effect and not part of the feature.


Adriano

[Mark Rotteveel]

On 22-10-2022 19:30, Adriano dos Santos Fernandes wrote:
> On 22/10/2022 11:43, Mark Rotteveel wrote:
>>>
>>> I don't see why such an exception should be added. Reserved words are
>>> reserved words and need to be quoted. Such odd exceptions to the rules
>>> can cause issues in other tools that need to parse queries,
>
> That's another issue. We're in the very bad situation that drivers do
> things that makes core evolution difficult.

I wasn't even thinking about drivers, but about (third-party) tools,
possibly generic and not necessarily Firebird specific, that perform
query-parsing, e.g. for syntax highlighting, query transformation, etc.

[..]

>> Also, consider the confusion this yields for statements in a package
>> body calling other functions or procedures declared in that package body
>> (which would require quoting(!)).
>>
>> For consistency sake, I don't like it.
>>
>
> Since the definition of the routines still requires the double quotes,
> it's not a big deal.

Which introduces another inconsistency in rules for quoting object names
that is hard to explain to users.

> It's why I called it a side effect and not part of the feature.

I don't think the minor benefits of this (not needing to use quotes) are
worth it.

If you want to avoid quoting at all costs, maybe consider brainstorming
on those names to try and come up with alternatives that won't require
quoting.

Mark
--
Mark Rotteveel

[Dmitry Yemanov]

24.10.2022 10:58, Mark Rotteveel wrote:

>>> Also, consider the confusion this yields for statements in a package
>>> body calling other functions or procedures declared in that package body
>>> (which would require quoting(!)).
>>>
>>> For consistency sake, I don't like it.
>>
>> Since the definition of the routines still requires the double quotes,
>> it's not a big deal.
>
> Which introduces another inconsistency in rules for quoting object names
> that is hard to explain to users.
>
>> It's why I called it a side effect and not part of the feature.
>
> I don't think the minor benefits of this (not needing to use quotes) are
> worth it.

I tend to agree.

> If you want to avoid quoting at all costs, maybe consider brainstorming
> on those names to try and come up with alternatives that won't require
> quoting.

The problem is that the most obvious method names (CREATE, OPEN, CLOSE)
for RDB$BLOB_UTILS are reserved words and it would only make things
harder to understand if we choose different names.

The obvious choice was using a _BLOB suffix, i.e. OPEN_BLOB,
CREATE_BLOB, etc., although I was against this due to "BLOB" already
present in the package name. But if we won't find any better solution,
I'll stop my complaints.


Dmitry

[Adriano dos Santos Fernandes]

Hi!

There is an alternative for this proposal with allows the desired
behavior (not invent artificial names for packaged system routines)
without the side effect (allow user routines to also used unquoted names
in only some places).

The alternative is to explicitly declare at parser special packaged
system routines, for example RDB$BLOB_UTIL.CLOSE.

-----
non_reserved_word
: ...
| RDB_BLOB_UTIL
;

%type <stmtNode> exec_procedure
exec_procedure
: EXECUTE PROCEDURE exec_procedure_name proc_inputs proc_outputs_opt
{ $$ = newNode<ExecProcedureNode>(*$3, $4, $5); }
;

%type <qualifiedNamePtr> exec_procedure_name
exec_procedure_name
: symbol_procedure_name
{ $$ = newNode<QualifiedName>(*$1); }
| symbol_package_name '.' symbol_procedure_name
{ $$ = newNode<QualifiedName>(*$3, *$1); }
| RDB_BLOB_UTIL '.' CLOSE
{ $$ = newNode<QualifiedName>(*$3, *$1); }
;
-----

The only drawback is that it creates a shift/reduce conflict, but
generally we accept them.

What do you think?


Adriano

[Mark Rotteveel]

On 02-12-2022 12:45, Adriano dos Santos Fernandes wrote:
> Hi!
>

I don't like. I don't see why using `CLOSE_BLOB` (etc) is not
acceptable. I understand the feeling that repeating BLOB is not "nice",
but I think it is preferable over parser hacks like this.

Mark
--
Mark Rotteveel

[Dmitry Yemanov]

02.12.2022 15:18, Mark Rotteveel wrote:

> I don't like. I don't see why using `CLOSE_BLOB` (etc) is not
> acceptable. I understand the feeling that repeating BLOB is not "nice",
> but I think it is preferable over parser hacks like this.

I was against names like CLOSE_BLOB, but given that other alternatives
are somewhat hackery, please don't count my opinion as a showstopper ;-)
I can live with CLOSE_BLOB and the like.


Dmitry

[Alex Peshkoff]

+1