 variable value's length is not checked during compilition [message #609972] |
Fri, 14 March 2014 15:32  |
harpreetsinghkup
Messages: 52
Registered: May 2006
Location: Mumbai
|
Member |
|
|
Hi,
You might think, what a rubbish question it is,,, but i just want to ask for my knowledge...
While, we creats procedure, it is not checking variable value's length at the compilition time? My below procedure is compiling properly but it is throughing error at run time, which is a right, but i want to understand the reason behind it...
Could you please help me out? Below is the code for your reference....
CREATE OR REPLACE PROCEDURE testing
AS
Lv_string VARCHAR2(5):='Testing of extra data '; --Value is having extra data
BEGIN
dbms_output.put_line(Lv_string);
END;
--Result appearing as
PROCEDURE testing compiled
--Execute the procedure, it will through error now...
EXECUTE testing;
---Result appearing as
Error report:
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at "scott.TESTING", line 3
ORA-06512: AT line 1
06502. 00000 - "PL/SQL: numeric or value error%s"
*/
[Updated on: Fri, 14 March 2014 15:34] Report message to a moderator |
|
|
|
|
|
| Re: variable value's length is not checked during compilition [message #610033 is a reply to message #609974] |
Mon, 17 March 2014 01:06  |
 |
vslabs
Messages: 26
Registered: March 2014
Location: Cape Town
|
Junior Member |
|
|
Unfortunately PL/SQL is not a strict type language.
You can pass a number data value as a string parameter. Or a string data value as date.
And you cannot enforce data type size (or precision) checking at compile time.
Which is unlike other languages like Pascal and C.
Some argue that not having strict type enforcement, results in easier and more flexible programming. Some argue that not having strict type enforcement, results in a less robust and more runtime error prone language.
Both are right.
Your job as a programmer is to understand the constraints of the language, and design and write robust code in the language. Be that Pascal, C, Java, or PL/SQL.
[Updated on: Mon, 17 March 2014 01:07] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: variable value's length is not checked during compilition [message #610063 is a reply to message #610034] |
Mon, 17 March 2014 05:13 |
|
vslabs
Messages: 26
Registered: March 2014
Location: Cape Town
|
Junior Member |
|
|
Michel Cadot wrote on Mon, 17 March 2014 09:34
I disagree.
Quote:You can pass a number data value as a string parameter. Or a string data value as date.
Because of implicit conversions (which are documented) not because types are not checked.
That is part of what I see as weak type checking by a compiler - allowing for implicit data conversions between types and not insisting on explicit conversions. If for example you pass a string as a number and the compiler accepts that, why would the compiler be bothered to determine if an assignment using a number to a numeric type is valid ito scale and precision?
There are no rigid acceptable definitions on what is a weak type and what is a strong type language. Have debated this many times and there are very different perspectives.
But predictability is one of they key issues to me. Take the following statement:
x := '6' + 1;
With x as a string, is the result '7' or '61'? (plus is used as concatenation in many languages). In some languages the result is '7'. In others it is '61'.
And this is one of the main issues that makes a language a weak (or weaker) type language. You cannot always predict from code, what the runtime results will be. Think of the issue we often see with PL/SQL code where dates are passed as strings and used as dates - and where having variable NLS date formats can parse that string as a valid and different date.
Quote:
Quote:And you cannot enforce data type size (or precision) checking at compile time.
Yes you can creating or declaring types.
What I meant is that you cannot create a subtype called NUM1 as a single digit number, use that as parameter type, and expect the compiler to tell you where in the code callers are passing NUMBER variables with more than one digit.
In Pascal for example, doing this will generate compiler errors (or warnings, depending on compiler and options used), indicating where callers are using an incorrect or problematic (range error at runtime) types.
|
|
|
|
|
|
| Re: variable value's length is not checked during compilition [message #610103 is a reply to message #610063] |
Mon, 17 March 2014 11:25 |
Solomon Yakobson
Messages: 3273
Registered: January 2010
Location: Connecticut, USA
|
Senior Member |
|
|
vslabs wrote on Mon, 17 March 2014 06:13But predictability is one of they key issues to me. Take the following statement:
x := '6' + 1;
With x as a string, is the result '7' or '61'? (plus is used as concatenation in many languages). In some languages the result is '7'. In others it is '61'.
I think you are very confused here. It doesn't matter if we assign '6' + 1 to number X, string X, date X, lob X, etc. - it has no effect on what + is - concatenation or arithmetic plus. Statement:
x := '6' + 1;
consists of two operators:
1) binary operator + against two operands - string '6' and number 1.
2) assignement operator - operation 1) result is assigned to variable x.
Let's talk about operation 1). If + is just arithmetic plus operator language can have just one rule: all operands are converted, if needed, to numbers and then added. Error is raised if operand can't be converted to number. If + is both arithmetic plus operator or concatenation operator language can have one of three rules:
Rule 1. + means arithmetic plus operation if both operands and numbers
Rule 2. + means concatenation operation if both operands are strings
Rule 3. which operator wins if we have mixed case. For example, in SQL Server where + is used both as plus and as concatenation + means arithmetic plus operation if at least one operand is numeric.
Anyway, it doesn't matter if language uses same token is used for multiple opertions, language always defines a set of rules allowing unique operator identifiction. And such rules have no bearing and are completely independent of other opertors. So again, it doesn't matter if we assign '6' + 1 to number X, string X, date X, lob X, etc. - it has no effect on what + is concatenation of arithmetic plus. Language rules will be applied to determine what + means and therefore what reult type is. Corresponding operation will be performed against '6' and 1 and result will be assigned to X which will trigger another set of language rules - what to do if types do not match. Anyway, if really want to learn compiler basics I suggest reading classics - Knuth's Compiler Design.
SY.
[Updated on: Mon, 17 March 2014 11:26] Report message to a moderator |
|
|
|
|
|
| Re: variable value's length is not checked during compilition [message #610319 is a reply to message #610294] |
Wed, 19 March 2014 07:21 |
Solomon Yakobson
Messages: 3273
Registered: January 2010
Location: Connecticut, USA
|
Senior Member |
|
|
vslabs wrote on Wed, 19 March 2014 04:08You are making assumptions that are not valid across all compilers and parsers/interpreters.
See http://en.wikipedia.org/wiki/Strong_and_weak_typing#Predictability for basic details - it addresses the same issue.
No, it is you who is making assumptions. Where does this article say "5" + 6 result in stemetent x = "5" + 6 depends on x type? It says "Different languages will assign a different value to 'x'", which is absolute true. But "5" + 6 result depends solely on operand types (types of "5" and 6) and operator + rules - not on x type. Then operator + result and x will become next operation (assignment) operands and now language assignment operator rules will be applied. And this is exactly what I said. What you said was:
Quote:Take the following statement:
x := '6' + 1;
With x as a string, is the result '7' or '61'?
I don't know what you meant exactly, but the above sounds like '6' + 1 result would be different depending on x type. And that was the part I objected to.
SY.
|
|
|
|
|
|
| Re: variable value's length is not checked during compilition [message #610475 is a reply to message #610428] |
Thu, 20 March 2014 08:01 |
Solomon Yakobson
Messages: 3273
Registered: January 2010
Location: Connecticut, USA
|
Senior Member |
|
|
Last attempt. SQL Server uses + as both arichmetic plus and concatenation:
DECLARE @I INT
DECLARE @S VARCHAR(10)
SET @I = '6' + 1
PRINT @I
SET @S = '6' + 1
PRINT @S
And both will print 7 since SQL Server rules are: if both operands are strings then + is concatenation otherwise it is arichmetic plus. It does not matter what is type of a variable we assign result of '6' + 1 to. In Sql Server it always results in number 7. What happens to that number 7 when it is assigned to a variable is another story, but that variable has no effect on '6' + 1 result. In case of @I in my example 7 will be assigned to I with no type conversions. In case of @S, integer 7 will be converted to string (VARCHAR). But again, neither @I nor @S affected result of '6' + 1. Next example:
DECLARE @D DATETIME
SET @D = '6' + 1
PRINT @D
The above will print Jan 8 1900 12:00AM. Why? Because no matter what in SQL Server '6' + 1 = 7 and assigning integer 7 to @D which is datetime forces SQL Server to convert integer 7 to datetime. And SQL Server rules on integer to datetime conversion are - integer is treated as offset in days from SQL Server epoch datetime Jan 1, 1900 12:00AM. As a result @D is assigned Jan 8 1900 12:00AM. But again @D datatype has no bearing on '6' + 1 result. To summarize In a statement X = Y + Z rezult of Y + Z doesn't depend on X type.
SY.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
