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