New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User-defined PSQL functions [CORE2047] #2483
Comments
Commented by: lacak (lacak) There is SQL:2003 CREATE FUNCTION command, which can also solve this issue. |
Commented by: @dyemanov Yes, the project's intention is to add full SQL2003 support for stored functions in FB 3.0. I also remember such a ticket already registered but I cannot find it at the moment either... However, stored procedures are not going to be supported as functions. |
Commented by: Alastair Breingan (alb) Thank you that would be excellent. I searched though all open tickets referring to function, and did not find anything. Agreed - we still need to distinguish between a stored procedure and a function. (the latter should probably only return a single value etc). |
Modified by: @dyemanovstatus: Open [ 1 ] => Open [ 1 ] Fix Version: 3.0.0 [ 10048 ] Component: Engine [ 10000 ] Planning Status: Unspecified => Considered for inclusion |
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Commented by: Cosmin Apreutesei (cosmin_ap2) awsome!!! |
Modified by: @dyemanovsummary: Allow PSQL procedures to be defined as "SQL Functions" that can be used in a similar way to UDF's => User-defined PSQL functions |
Modified by: @pavel-zotovQA Status: No test |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Covered by another test(s) |
Submitted by: Alastair Breingan (alb)
Is related to QA633
Votes: 10
It would seem logical and fairly simple (isn't it always when you are not doing the work?) to allow a PSQL procedure to be defined as a SQL or PSQL function. This would simplify the syntax when incorporating these into select statements etc.
For example it is already possible to
select a.*, (select * from GrossProfit(Item)) from ItemMaster
or
select * from ItemMaster where (select * from GrossProfit(Item)) > 30
This proposal would allow the following code without having to write UDF's, which I prefer to restrict to complex computationally intensive code that does not reference the database.
select a.*, GrossProfit(Item) from ItemMaster
or
select * from ItemMaster where GrossProfit(Item) > 30
While the difference is initially not great, I find that these functions are very useful and rapidly become a major part of a business system, at which point the code looks very unwieldy.
The text was updated successfully, but these errors were encountered: