Menu
▾
▴
firebird-devel
|
From: Dmitry Y. <fir...@ya...> - 2010-01-15 13:17:30
|
Adriano, >> Another related thing (from memory, so I may be imprecise) could be to >> still parse the (non-null) output sqlda but don't recreate the output >> message every time. > > ... > >> Just compare the current sqlda with the priorly used >> one and reuse the last message if sqlda hasn't changed. >> > I thought on storing the last sqlda value and comparing it with the passed one, and totally skip the UTLD call. > > It would make applications faster automatically, but there will be a potential problem, if the user pass the same sqlda with something changed. I don't think users are doing that, but is something valid currently. > > Do you mean the same thing? Supposedly, yes :-) But I don't see what "something" can be changed by the user for the output sqlda. The destination address? We could ignore it when comparing two sqlda's for "equality" but still use it when copying the returned data from the message. Dmitry |
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-15 13:27:10
|
Dmitry Yemanov wrote: >> It would make applications faster automatically, but there will be a potential problem, if the user pass the same sqlda with something changed. I don't think users are doing that, but is something valid currently. >> >> Do you mean the same thing? > > Supposedly, yes :-) But I don't see what "something" can be changed by > the user for the output sqlda. The destination address? We could ignore > it when comparing two sqlda's for "equality" but still use it when > copying the returned data from the message. > Theoretically, currently the user can change any sqlvar content, so he can fetch a first time in an integer column and a second time in a varchar column. He also can free the sqlda and alloc another one that by coincidence receives the same memory address. I.e., these are things difficult to expect, but we know users. :-) Adriano |
|
From: Alexander P. <pes...@ma...> - 2010-01-15 14:13:14
|
On Friday 15 January 2010 16:26:53 Adriano dos Santos Fernandes wrote: > Dmitry Yemanov wrote: > >> It would make applications faster automatically, but there will be a > >> potential problem, if the user pass the same sqlda with something > >> changed. I don't think users are doing that, but is something valid > >> currently. > >> > >> Do you mean the same thing? > > > > Supposedly, yes :-) But I don't see what "something" can be changed by > > the user for the output sqlda. The destination address? We could ignore > > it when comparing two sqlda's for "equality" but still use it when > > copying the returned data from the message. > > Theoretically, currently the user can change any sqlvar content, so he can > fetch a first time in an integer column and a second time in a varchar > column. > > He also can free the sqlda and alloc another one that by coincidence > receives the same memory address. > > I.e., these are things difficult to expect, but we know users. :-) If you plan to compare sqlda's by ptr, I'm afraid this is for sure something wrong. |
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-15 14:06:08
|
Alexander Peshkoff wrote: >> >> He also can free the sqlda and alloc another one that by coincidence >> receives the same memory address. >> >> I.e., these are things difficult to expect, but we know users. :-) > > If you plan to compare sqlda's by ptr, I'm afraid this is for sure something > wrong. Yes, that's what I feel. :-) So we can do it with memcmp and still do faster using new semantics (second fetch with NULL sqlda or sqlda passed to execute). The memcmp way will certainly be faster than current way, and will work automatically. Adriano |
|
From: Dmitry Y. <fir...@ya...> - 2010-01-15 14:21:40
|
Adriano dos Santos Fernandes wrote: > Theoretically, currently the user can change any sqlvar content, so he can fetch a first time in an integer column and a second time in a varchar column. And we must handle this by comparing the entire sqlda contents, including sqlvars (data types, lengths, etc). Not by just comparing the address of the passed sqlda. This is why I said that parsing would still be required. Dmitry |
|
From: Carlos H. C. <li...@wa...> - 2010-01-04 15:22:41
|
This is not the same thing, but as you are talking enhancing custom exception messages, I would like to see a way to have custom error messages for some constraints types, specially check constraints. When you define the constraint, you also define the error message that it will throw. Vlad told me that probably there is already a ticket in the tracker asking for this, but I can't check it, since tracker is still offline. []s Carlos http://www.warmboot.com.br FireBase - http://www.FireBase.com.br AdSF> Currently user can't create good exception texts and rely on them, AdSF> because exceptions generally need more informations. So user need to AdSF> throw exceptions passing its complete text [exception e1 'Exception ' || AdSF> info1 || ' at ' || info2]. This lose the ability to create exception AdSF> texts and to catch the parameters without parse the formated text. |
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-04 15:39:39
|
Carlos H. Cantu wrote: > This is not the same thing, but as you are talking enhancing custom > exception messages, I would like to see a way to have custom error > messages for some constraints types, specially check constraints. When > you define the constraint, you also define the error message that it > will throw. > > Vlad told me that probably there is already a ticket in the tracker > asking for this, but I can't check it, since tracker is still offline. > Yes, there is and that is very useful. It's good to think on it with parameterized exception in mind, because it would be better stored on the metadata as an exception statement BLR instead of just the exception name. Adriano |
|
From: Claudio V. C. <cv...@us...> - 2010-01-05 02:17:27
|
> -----Original Message-----
> From: Adriano dos Santos Fernandes [mailto:adr...@gm...]
> Sent: Lunes, 04 de Enero de 2010 11:16
>
> If that exception is thrown in the new way [exception e1
> ('foo', 'bar')]
> the exception will be see formated. To format it, it will be
> encoded in
> this way:
> isc_except, <number>,
> isc_random, <string>, <string: foo>, <string: bar>
>
> The formating routine will treat isc_random in especial way, and will
> format its string using the others parameters till the status
> vector end
> or the next isc code. As isc_random is currently always generated with
> one parameter, no compatibility problem will arise.
It's a nice extension for the people that need it.
- How do you parse the new encoding?
- Are you going to extend fb_interpret?
C.
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-05 14:46:56
|
Adriano dos Santos Fernandes wrote:
> If that exception is thrown in the new way [exception e1 ('foo', 'bar')]
And this is ambiguous syntax, with [exception e1 <expr>] syntax when
only one parameter is used. Anyone willing to suggest some other?
Adriano
|
|
From: Dmitry Y. <fir...@ya...> - 2010-01-05 16:26:59
|
Adriano dos Santos Fernandes wrote:
>> If that exception is thrown in the new way [exception e1 ('foo', 'bar')]
>
> And this is ambiguous syntax, with [exception e1<expr>] syntax when
> only one parameter is used.
Why ambiguous, provided that parenthesis would be mandatory?
Dmitry
|
|
From: Dimitry S. <sd...@ib...> - 2010-01-05 16:31:18
|
> Adriano dos Santos Fernandes wrote:
>
>>> If that exception is thrown in the new way [exception e1 ('foo', 'bar')]
>> And this is ambiguous syntax, with [exception e1<expr>] syntax when
>> only one parameter is used.
>
> Why ambiguous, provided that parenthesis would be mandatory?
In expressions they are optional, but still not prohibited. Consider
this:
exception e1 (StringOne || String Two);
SY, SD.
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-05 16:31:49
|
Dmitry Yemanov wrote:
> Adriano dos Santos Fernandes wrote:
>
>>> If that exception is thrown in the new way [exception e1 ('foo', 'bar')]
>> And this is ambiguous syntax, with [exception e1<expr>] syntax when
>> only one parameter is used.
>
> Why ambiguous, provided that parenthesis would be mandatory?
>
Because I can already do:
exception ex ('replacement text');
That means different thing than:
exception ex ('single parameter');
Adriano
|
|
From: Claudio V. C. <cv...@us...> - 2010-01-06 03:49:22
|
> -----Original Message-----
> From: Adriano dos Santos Fernandes [mailto:adr...@gm...]
> Sent: Martes, 05 de Enero de 2010 13:32
>
> Dmitry Yemanov wrote:
> >
> > Why ambiguous, provided that parenthesis would be mandatory?
> >
> Because I can already do:
> exception ex ('replacement text');
>
> That means different thing than:
>
> exception ex ('single parameter');
And what's wrong with using another delimiter instead of a pair of
parentheses?
Square brackets [],
angle brackets (the beloved < and > of Dmitry S),
curly braces {}, etc.
C.
|
|
From: Dmitry Y. <fir...@ya...> - 2010-01-06 08:30:26
|
Claudio Valderrama C. wrote:
>> exception ex ('single parameter');
>
> And what's wrong with using another delimiter instead of a pair of
> parentheses?
> Square brackets [],
> angle brackets (the beloved< and> of Dmitry S),
> curly braces {}, etc.
Please no :-)
I'd rather vote for something more explicit, e.g.:
exception ex using [arguments] (<arg1>, ...)
Dmitry
|
|
From: Alexander P. <pes...@ma...> - 2010-01-06 08:53:56
|
On Wednesday 06 January 2010 11:30:18 Dmitry Yemanov wrote:
> Claudio Valderrama C. wrote:
> >> exception ex ('single parameter');
> >
> > And what's wrong with using another delimiter instead of a pair of
> > parentheses?
Suppose violation SQL language style. It's not C++ :)))
> > Square brackets [],
> > angle brackets (the beloved< and> of Dmitry S),
> > curly braces {}, etc.
>
> Please no :-)
>
> I'd rather vote for something more explicit, e.g.:
>
> exception ex using [arguments] (<arg1>, ...)
Yep, USING, WITH or something in this style.
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-06 13:19:56
|
Alexander Peshkoff wrote:
> On Wednesday 06 January 2010 11:30:18 Dmitry Yemanov wrote:
>> Claudio Valderrama C. wrote:
>>>> exception ex ('single parameter');
>>> And what's wrong with using another delimiter instead of a pair of
>>> parentheses?
>
> Suppose violation SQL language style. It's not C++ :)))
>
>>> Square brackets [],
>>> angle brackets (the beloved< and> of Dmitry S),
>>> curly braces {}, etc.
>> Please no :-)
>>
>> I'd rather vote for something more explicit, e.g.:
>>
>> exception ex using [arguments] (<arg1>, ...)
>
> Yep, USING, WITH or something in this style.
>
I was thinking on WITH and less better VALUES/PARAMETERS. USING seems
better for me.
Adriano
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X