Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

G-8310: Make guideline less strict by limiting the scope of data types #182

Closed
Assignees
PhilippSalvisberg
Labels
enhancementNew feature or request
Milestone
@PhilippSalvisberg

Description

@PhilippSalvisberg

As mentioned in#181 the guideline is too strict IMO.

There are some cases where a violation can be considered a false positive. For example for the following data types (based onSQL Language Reference 19c) :

  • BINARY_FLOAT
  • BINARY_DOUBLE
  • LONG
  • LONG RAW
  • DATE
  • BLOB
  • CLOB
  • NCLOB
  • BFILE
  • ROWID
  • INTEGER
  • DOUBLE PRECISION
  • REAL
  • ...

For these datatypes it is not possible to define asize or aprecision andscale. So the data type of the parameter is always fully qualified. It's not passible that aVALUE_ERROR is thrown when assigning the parameter value to a local variable of the same data type.

So, I suggest to limit the check to chosen data types, where we know that asize,precision orscale can be relevant andVALUE_ERROR is possible and in the responsibility of the caller. Here's the full list:

Data typeOptional size/precision/scale/...?Comment
CHARNo
VARCHAR2No
NCHARYesThe default is a single character, the length of the parameter is undefined, hence relevant.
NVARCHAR2No
NUMBERYesThrows a value_error, hence relevant.
FLOATYesValue is rounded, does not throw a value_error, hence irrelevant.
RAWNo
TIMESTAMPYesValue is rounded, does not throw a value_error, hence irrelevant.
INTERVAL YEAR TO MONTHYesThrows a value_error, hence relevant.
INTERVAL DAY TO SECONDYesThrows a value_error, hence relevant.
UROWIDYesDoes not throw a value_error, should not be used anyway, hence irrelevant
CHARACTER [VARYING]No
VARCHARNo
NATIONAL CHAR[ACTER] [VARYING]No
NUMERICYesThrows a value_error, hence relevant.
DECIMALYesThrows a value_error, hence relevant.
DECYesThrows a value_error, hence relevant.
...%TYPEYesWe do not know anything about the datatype, can be VARCHAR2 (relevant) or DATE (irrelevant), hence relevant.

When limiting the guideline to these data types some false negatives are possible. E.g when defining a constrained subtype. With static code analysis and a limited scope of a file that's probably unavoidable to reduce the number of false positives.

Metadata

Metadata

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions


    [8]ページ先頭

    ©2009-2025 Movatter.jp