[Firebird-devel] [FB-Tracker] Created: (CORE-6300) Next attachment id, next statement id
Next attachment id, next statement id - Key: CORE-6300 URL: http://tracker.firebirdsql.org/browse/CORE-6300 Project: Firebird Core Issue Type: New Feature Components: Engine Reporter: Karol Bieniaszewski Please provide easy access to the info: - next attachment id - next statement id Currently we can read in easy way only next transaction id as MON$NEXT_TRANSACTION in MON$DATABASE. Next statement id we can read from joining current attachment with mon$statements. But next attachment id can be read only by statistics service (reading header page) and it does not show real time values only some "updated one" and not correlated with current snapshot of database state taken by MON$ tables. Of course we can made new connection - but this is to costly and not natural way. This info can be used to monitor database e.g. how many new attachements are done during period. In a period there can be many short leaving attachment and reading MON$ATTACHEMNT can simply miss it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Default/implicit/built-in functions via external engines
Hi, I'm wondering whether it would make sense from engine's POV to have an ability for the external engine plugin to provide default/implicit/built-in functions - aka function that are always available (like built-in) and do not require registration (by using create function/procedure/...) in the database? Obviously these functions will be limited (mostly I think because of dependencies), but even with that it's still worthy from my POV. Looking for ideas and arguments... :) -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Default/implicit/built-in functions via external engines
On 2020-05-11 11:13, Jiří Činčura wrote: Hi, I'm wondering whether it would make sense from engine's POV to have an ability for the external engine plugin to provide default/implicit/built-in functions - aka function that are always available (like built-in) and do not require registration (by using create function/procedure/...) in the database? Obviously these functions will be limited (mostly I think because of dependencies), but even with that it's still worthy from my POV. Looking for ideas and arguments... :) How would the engine know about these functions if they aren't registered? The thing that differentiates built-in functions from 'normal' functions is that they are handled using keywords in the statement parser instead of being registered in RDB$FUNCTIONS. Do you propose an automatic registration procedure? I think that is risky, and should rather be part of the installation steps of an external engine. Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Default/implicit/built-in functions via external engines
>Much better would be if engine ask the plugin for list of provided > routines and don't > require the registration at all. But this creates an egg-and-chicken Sometimes the plugin does not know that in advance. So I suppose the registration is still a valid path. > problem: how to find > the plugin. Loading of all libraries in plugin directory would be a > security problem. True. Although the plugins.conf can have a switch for "pre-loading". -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Default/implicit/built-in functions via external engines
11.05.2020 11:13, Jiří Činčura wrote: I'm wondering whether it would make sense from engine's POV to have an ability for the external engine plugin to provide default/implicit/built-in functions - aka function that are always available (like built-in) and do not require registration (by using create function/procedure/...) in the database? Much better would be if engine ask the plugin for list of provided routines and don't require the registration at all. But this creates an egg-and-chicken problem: how to find the plugin. Loading of all libraries in plugin directory would be a security problem. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Default/implicit/built-in functions via external engines
> Do you propose an automatic registration procedure? Frankly I don't propose anything implementation-wise. I'm just about gathering ideas, willingness and maybe understanding the feature more in an open discussion. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Default/implicit/built-in functions via external engines
11.05.2020 12:13, Jiří Činčura wrote: Hi, I'm wondering whether it would make sense from engine's POV to have an ability for the external engine plugin to provide default/implicit/built-in functions - aka function that are always available (like built-in) and do not require registration (by using create function/procedure/...) in the database? Obviously these functions will be limited (mostly I think because of dependencies), but even with that it's still worthy from my POV. Looking for ideas and arguments... :) Look like you want to invent some kind of extensions ;) To make it work, engine should know about plugins that contain such extension and list of routimes with its call signatures. I.e. some kind of metadata. First task could be solved using standard configuration file - i.e. admin must add name of plugin to the corresponding setting. Second task could be solved introducing new interface that plugin should implement and engine use\consume. One more task is to make our SQL parser know about extensions. Am I missing something ? Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Default/implicit/built-in functions via external engines
11.05.2020 14:24, Vlad Khorsun wrote: To make it work, engine should know about plugins that contain such extension and list of routimes with its call signatures. I.e. some kind of metadata. UDRs already provide information about input/output parameters. The only missed interface (method) is to enum provided functions. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Default/implicit/built-in functions via external engines
11.05.2020 15:33, Dimitry Sibiryakov wrote: 11.05.2020 14:24, Vlad Khorsun wrote: To make it work, engine should know about plugins that contain such extension and list of routimes with its call signatures. I.e. some kind of metadata. UDRs already provide information about input/output parameters. The only missed interface (method) is to enum provided functions. Good, less things to do Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
