Re: [Firebird-devel] System procedures

[Roman Simakov]

2018-05-28 8:02 GMT+03:00 Dmitry Yemanov :
> 28.05.2018 04:04, Adriano dos Santos Fernandes wrote:
>>
>>
>> I'm adding system procedure support, coded in C++, initially for list
>> time zone rule transition, as it can't be done with virtual table (needs
>> parameters).
>>
>> I see others great potentials with this. We can also later code system
>> triggers with them, as they are currently coded directly in BLR and are
>> unmaintainable.
>
>
> I'd rather get rid of them at all, replacing with built-in VIO-level
> processing. We already did that for some.

I'm trying to do it for trigger1 right now because it do not cover
some new objects privileges and it's really hard to maintain.

-- 
Roman Simakov

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] System procedures

[Dmitry Yemanov]

28.05.2018 04:04, Adriano dos Santos Fernandes wrote:


I'm adding system procedure support, coded in C++, initially for list
time zone rule transition, as it can't be done with virtual table (needs
parameters).

I see others great potentials with this. We can also later code system
triggers with them, as they are currently coded directly in BLR and are
unmaintainable.


I'd rather get rid of them at all, replacing with built-in VIO-level 
processing. We already did that for some.



For system tables, their IDs starts with 0, while user tables starts at 128.

User procedures already starts with 0, so initially I'm creating system
procedures with negative IDs.


I suppose you assign IDs directly, without generator usage? So it 
remains initialized with zero?



Anyone see a problem with that?


I suspect some code pieces may treat IDs as USHORT. It's harmless per 
se, but problems may arise after promoting those unsigned IDs to ULONG. 
I'm not sure it happens, but it's worth checking.



Dmitry

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] System procedures

[Adriano dos Santos Fernandes]

Hi!

I'm adding system procedure support, coded in C++, initially for list
time zone rule transition, as it can't be done with virtual table (needs
parameters).

I see others great potentials with this. We can also later code system
triggers with them, as they are currently coded directly in BLR and are
unmaintainable.

For system tables, their IDs starts with 0, while user tables starts at 128.

User procedures already starts with 0, so initially I'm creating system
procedures with negative IDs.

Anyone see a problem with that?


Adriano

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] RFC: External Connections Pool

[Vlad Khorsun via Firebird-devel]

23.05.2018 15:07, Adriano dos Santos Fernandes wrote:

On 23/05/2018 08:51, Vlad Khorsun via Firebird-devel wrote:

23.05.2018 13:40, Adriano dos Santos Fernandes wrote:

On 23/05/2018 06:48, Dimitry Sibiryakov wrote:


    In this case I guess there must be two triggers: BEFORE RESET and
AFTER RESET.


I like this more than the other approaches.


   I strongly suggest to consider existing DISCONNECT\CONNECT triggers
also. I think, most of the code will be the same in both set of events
therefore it is very questionable if we need another pair of triggers.



Yes, but for me it seems as a hack. User can always do a single SP and
call it on both triggers.


  Hmm... do you consider INSERT OR UPDATE OR DELETE triggers as hack also ?


I have an idea with I think is good.

What if RESET resets not to the initial (before ON CONNECT) state, but
to the state present after ON CONNECT?


  It means we should know what changes was made by ON CONNECT trigger.
I.e. we need to save names and values of context variables, save values
of session properties and save contents of GTT's.
  Looks overkill for me.


So ON CONNECT can define context variables that is not reset.


  You mean - all context variables in USER_SESSION namespace that was
assigned by ON CONNECT trigger ? Or you speak about some way to mark
context variables as "DON'T RESET" ?

Regards,
Vlad

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] [FB-Tracker] Created: (CORE-5834) Provide DDL to change external table file name

[Karol Bieniaszewski (JIRA)]

Provide DDL to change external table file name
--

 Key: CORE-5834
 URL: http://tracker.firebirdsql.org/browse/CORE-5834
 Project: Firebird Core
  Issue Type: New Feature
  Components: Engine
Reporter: Karol Bieniaszewski


As proposed by Mark Rotteveel on support list
please provide DDL to change file name of external table

ALTER TABLE  ALTER EXTERNAL [FILE] 

-- 
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



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel