Altering a procedure called by another procedure doesn't recompile parent
-
Key: CORE-5065
URL: http://tracker.firebirdsql.org/browse/CORE-5065
Project: Firebird Core
Is
Hi all,
We have an annoying little problem. The visible manifestation is that
literals in CASE expressions could be padded with spaces.
Here is simplified example:
set term ^;
create procedure tmp_sp(pParam integer)
returns (selectionIf varchar(40), selectionCase varchar(40))
as
declare vari
I start wondering if nowadays, saying that a RDBMS "complies to the SQL
Standard" is seem by the users as a "plus".
Most of the time, I saw this as a good way to say: "Ok, Firebird is
Standard compliant, so you can move easily from another RDBMS to it".
But seems that all the others RDBMS don't ca
05.01.2016 16:31, Pavel Cisar wrote:
>
> We have an annoying little problem.
We have it for the past decade, so I agree with describing this problem
as a "little" one ;-)
> To sum it up, standard dictates that literals are CHARs, aggregated
> values has length of longest one and because CHARs ar
On 05/01/2016 11:31, Pavel Cisar wrote:
> Hi all,
>
> We have an annoying little problem. The visible manifestation is that
> literals in CASE expressions could be padded with spaces.
>
>
We also have DECODE. Let's see it:
SQL> select 'a' || decode(1, 1, 'a', 2, 'b') || 'c' from rdb$database;
On 05/01/16 14:37, Dmitry Yemanov wrote:
> These examples say nothing about the approach used there: either
> literals are VARCHARs, or CASE derives the datatype differenly, or both.
>
> And I suppose Firebird is not really alone, see for MariaDB:
>
> CASE ... THEN 'a' ... THEN 'abcd' ... ELSE '
Hallelujah, Carlos!
At MySQL, I argued for SQL compliance until I was blue in the face but
without noticeable effect.
Database systems should have strings. Period. Not fixed strings,
variable strings, or bounded strings. String comparisons should be
blank extended. Nobody should ever have
FBSVCMGR produces "Missing arg #1 - possibly status vector overflow" when its
command includes >= 5 switches and all of them aren't allowed for
non-privileged user
-
Dmitry,
> > To sum it up, standard dictates that literals are CHARs, aggregated
> > values has length of longest one and because CHARs are padded with
> > spaces to declared length, we have such stupid output in CASE. Sure,
> > it could be easily "fixed" with CAST or TRIM, but it's extremely
> > a
Blocking new connections as a consequence of the too long sweep security2.fdb
--
Key: CORE-5067
URL: http://tracker.firebirdsql.org/browse/CORE-5067
Project: Firebird Core
gbak with invalid parameter crashes FB
--
Key: CORE-5068
URL: http://tracker.firebirdsql.org/browse/CORE-5068
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.5
Reporter: Carlos
> P.S. The fact that a fix for this could introduce compatibility issues is
> not a something we should care about when fixing invalid/wrong
> functionality. Compatibility issues are items which developers need to
> resolve for themselves, nothing is forcing a developer to adopt v3.
Well.
Improper call of "daemon" shell function in rc startup script leads to
"dirname" error
--
Key: CORE-5069
URL: http://tracker.firebirdsql.org/browse/CORE-5069
Project:
No, please no. I can find some logic in changing the concatenation behavior as
described (as I think that the standard might offer some leeway there, although
I need to study on it first), but changing the math that is clearly described
in the standard to something else is plain wrong.
Mark
---
06.01.2016 10:28, Mark Rotteveel wrote:
> No, please no.
I believe Arno was writing with the sarcasm mode turned on ;-)
Dmitry
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/list
My sarcasm detector is not so good.
Mark
- Reply message -
Van: "Dmitry Yemanov"
Aan: "For discussion among Firebird Developers"
Onderwerp: [Firebird-devel] Literals in CASE expression
Datum: wo, jan. 6, 2016 08:37
06.01.2016 10:28, Mark Rotteveel wrote:
> No, please no.
I believe Ar
06.01.2016 00:49, Leyne, Sean wrote:
>
>> First of all, let's distinguish between two things: (1) how string literals
>> are
>> described and (2) how CASE evaluates the resulting datatype. Changing any
>> of them may lead to the desired result.
>
> The issue is not the intermediate datatype but th
17 matches
Mail list logo
