On 2014.05.05. 9:27, Dmitry Yemanov wrote: > 05.05.2014 11:05, Molnár Attila wrote: >> I'm createing domains, and using TYPE OF. But as I write it's not >> enough. This is just for variable declaration but I need a pair in PSQL >> body. Maybe this example would help to understand. >> >> EXECUTE BLOCK >> AS >> DECLARE VARIABLE tmp TYPE OF COLUMN rdb$database.rdb$character_set_name; >> DECLARE VARIABLE i INTEGER; >> BEGIN >> i = 1; >> WHILE (i <= 31)--I want avoid hard coded 31 with "SIZE OF tmp" OR >> SIZE OF COLUMN rdb$database.rdb$character_set_name >> DO BEGIN >> --some logic here >> i = i + 1; >> END >> END > Now I see your point, thanks. > >>>> *increase or remove completly the context limit* (not the context >>>> variable but the table/view/sp stream, current limit is 255) >>>> - gain : performance (bigger EXECUTE BLOCK with more DML, e.g.: a >>>> lot of INSERT in a single SQL command) >>> Multi-value (multi-row) INSERT would serve the same goal without >>> affecting the context limit. Batch DML API would also allow remove the >>> need for EXECUTE BLOCK to execute batch INSERTs. >>> >>> Why else would you need a bigger EXECUTE BLOCK? > > >> I won't if these two are available. I wasn't aware of them. > They are not available, but they're the proper solution to the problem > and should be considered instead. > >>>> *TRIGGER : NEW/OLD values accessible by column name, and column number >>>> (PSQL)* >>>> - e.g.: NEW['id'], NEW[0] >>>> - gain : code reduction, dynamic code (don't have to alter the >>>> trigger ICO the table structure altered) >>> Dynamic code is not going to work reliably, unless you just iterate >>> fields in the loop. In this case, I see it just as a feature misuse, >>> some other solution may be required instead. >> It's about iteration. Define "misuse". > Iterator and ordinal number are two different things, even if they can > be implemented the same way. I don't want ordinal numbers for iterating > *only*, as people will start using them for other purposes finally > shooting themselves in the foot. Access by name only is good for me. (BTW I just realised that in this case it would great to have a VARIANT data type) > >>>> - GDSCODE_ORI, SQLCODE_ORI, ERRORMESSAGE_ORI : execute statement >>>> errors on external database hides the original error code, you should >>>> access them with these > > >>> Maybe an ability to iterate all status vection arguments would be a >>> better (and more generic) solution? > > >> Status vectos is at API level if I'n not mistaken. What about PSQL level? > This is exactly my point - PSQL access to the status vector. E.g. > besides GDSCODE, make available also GDSCODE[n] or whatever iteration > solution we choose. > >>>> *performance info* >>>> - ms is not so accurate and it seems also affecte by the thread >>>> time slice size. Need a more accurate measure : maybe gettickcount? >>> What performance info do you mean here? CPU time reported by ISQL? >> anything is a good candidate which has better scaleing than the curreny one. > My question was what "bad one" / "current one" do you mean? AFAIR, the > only one we have now is what ISQL reports (via perf API). Is this what > you're talking about? Very fast stored procedures run time can't be measuerd standalone, have to build an EXECUTE BLOCK and repeate many times then divide the run time to get average run time. But in this case there are also side effects (like HW cache, branch prediction, server side statement cache, data cache, etc...) and overhead which influences the measurement.
Currenty on my XP it reports 0ms or 16ms runtime, but nothing in between. (this number suggest me the thread time slice size percision of the current one) > > Dmitry > > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find out: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
