I'm reviewing dozens of SQL Server 2017 stored procedure query execution plans. I just noticed that one of the stored procedures is named "getDate". The procedure "seems" to work, and according to this "getDate" isn't a reserved keyword, but I'm bothered by the potential confusion with the GETDATE() function. I don't have a lot of time right now to comb through all of the potentially impacted code modules editing calls to this stored procedure. Is this something I can ignore for now and fix later, or is it likely causing problems such that I should fix it right away? I don't see any problems, apart from (presumably unrelated) super-slow running queries--which is why I'm reviewing the execution plans. The estimated execution plan for this "getDate" stored procedure looks OK though.
It's not recommended to keep the same name for the stored procedure. It would create so much chaos when you think long run and if you have enough time and privilege, change the name using SP_RENAME proc.
But at the same time, it would not throw error. Because GETDATE function is a database object in SQL Server and supports only SELECT or read data. What we can create is a stored procedure with the same name of database objects. So we are able to do DDL things to the user defined database objects.