I am using below code to do calculation
select column1 from tablename where code SIMILAR TO '%(-|_|–)EST[1-2][0-9](-|_)%'
for this column value -CSEST190-KCY18-04-01-L the condition was passed, but in actual I want to ignore this type of data.
The correct value which should pass through the above condition is
-CS-EST19-0-KCY18-04-01-L
-CS_EST19-0-KCY18-04-01-L
Any suggestions, how to avoid this type of confusion?
Easiest way is to go full-regex, instead of using SQL standard SIMILAR TO.
select column1 from tablename where code ~ '[_–-]EST[12][0-9][_-]'
Notice this is does not have to match the full string, and you don't have to add .* on both ends (equivalent of % in LIKE and SIMILAR TO). The reason you got a match on that is, because of the underscore _, which is a single wildcard character.
Also, I switched the order, in the square brackets, so that the dash is the last character. That way it's treated as a character literal, not as a range specifier.
Related
Let's say I want to use the character 倀:
https://www.fileformat.info/info/unicode/char/20480/index.htm
How would I type this into a query in BigQuery with the proper escape sequence? My thought was the following, but this seems like it's not correct based on the Lexical Structure:
SELECT '倀', '\U00020480'
But obviously that's not correct as I'm getting:
How would I properly type it in with the escape code?
Consider below "hint"
SELECT '倀', CODE_POINTS_TO_STRING([00020480])
with output
This simple example shows the issue I've run into, but I don't understand why...
I'm testing for the location of the first character that is either a lower or upper case letter, a single dash, or a period in a string parameter passed to me.
These two pattern matches appear to check the same thing, and yet run this code yourself and it will print a 0 then a 3:
PRINT PATINDEX ( '%[a-z,A-Z,-,.]%', '16-82')
PRINT PATINDEX ( '%[-,a-z,A-Z,.]%', '16-82')
I don't understand why it works only if the dash character is the first one we check for.
Is this a bug? Or working as designed and I missed something... I'm using SQL Server 2016, but I don't think that matters.
A dash within a character group may play either of the two roles:
It may denote the dash itself, like it does in the expression [-abc]
It may denote the "everything inbetween" operator, like it does in the expression [a-z].
In your particular example, the character group [a-z,A-Z,-,.] denotes the following:
Everything from a to z
Comma ,
Everything from A to Z
Everything from , to , (i.e. just the comma again).
Dot .
In fact, you probably wanted to write [-a-zA-Z.]
I have to create a procedure with same parameters names as excel columns. Some loook like this 'xxx/xxx' or 'xxx - xxx'. Is there any work around to name parameteres in a stored procedure like this?
Forward slash (/) or dash (-) are not allowed in variable names
According to http://msdn.microsoft.com/en-us/library/ms175874.aspx, that means that the allowed characters are:
Letters as defined in the Unicode Standard 3.2. The Unicode
definition of letters includes Latin characters from a through z,
from A through Z, and also letter characters from other languages.
Decimal numbers from either Basic Latin or other national scripts.
The at sign (#), dollar sign ($), number sign (#), or underscore (_).
Okay first of all why would you ever want to use special characters? That is like saying I want to fry toast underwater with electricity, why can't I have an outlet to allow that? Special characters denote special things and as such many engines, not just in SQL, but most languages will not allow reserved characters for use in variables. The best you could do was put in parameters with the reversed '_' and then replace that AFTER the object was already created for echoing out. The placeholder name of '#(something)' is really arbitrary and could be #X or #LookAtMe. It's type is important to form a contract that must be fulfilled for execution but the naming is really for hooking up. Having said that if you just must have these weird names echoed out you could do something like this:
CREATE PROC pSimpleParam #My_Param INT
AS
SELECT #My_Param
GO
ALTER PROC pSimpleParam #My_Param INT
AS
SELECT
pr.name AS ParameterName
, REPLACE(pr.name, '_', '-') AS AlteredParameterName
FROM sys.procedures p
INNER JOIN sys.parameters pr ON pr.object_id = p.object_id
AND p.name = 'pSimpleParam'
GO
I want to find rows where a text column begins with a user given string, e.g. SELECT * FROM users WHERE name LIKE 'rob%' but "rob" is unvalidated user input. If the user writes a string containing a special pattern character like "rob_", it will match both "robert42" and "rob_the_man". I need to be sure that the string is matched literally, how would I do that? Do I need to handle the escaping on an application level or is it a more beautiful way?
I'm using PostgreSQL 9.1 and go-pgsql for Go.
The _ and % characters have to be quoted to be matched literally in a LIKE statement, there's no way around it. The choice is about doing it client-side, or server-side (typically by using the SQL replace(), see below). Also to get it 100% right in the general case, there are a few things to consider.
By default, the quote character to use before _ or % is the backslash (\), but it can be changed with an ESCAPE clause immediately following the LIKE clause.
In any case, the quote character has to be repeated twice in the pattern to be matched literally as one character.
Example: ... WHERE field like 'john^%node1^^node2.uucp#%' ESCAPE '^' would match john%node1^node2.uccp# followed by anything.
There's a problem with the default choice of backslash: it's already used for other purposes when standard_conforming_strings is OFF (PG 9.1 has it ON by default, but previous versions being still in wide use, this is a point to consider).
Also if the quoting for LIKE wildcard is done client-side in a user input injection scenario, it comes in addition to to the normal string-quoting already necessary on user input.
A glance at a go-pgsql example tells that it uses $N-style placeholders for variables... So here's an attempt to write it in a somehow generic way: it works with standard_conforming_strings both ON or OFF, uses server-side replacement of [%_], an alternative quote character, quoting of the quote character, and avoids sql injection:
db.Query("SELECT * from USERS where name like replace(replace(replace($1,'^','^^'),'%','^%'),'_','^_') ||'%' ESCAPE '^'",
variable_user_input);
To escape the underscore and the percent to be used in a pattern in like expressions use the escape character:
SELECT * FROM users WHERE name LIKE replace(replace(user_input, '_', '\\_'), '%', '\\%');
As far as I can tell the only special characters with the LIKE operator is percent and underscore, and these can easily be escaped manually using backslash. It's not very beautiful but it works.
SELECT * FROM users WHERE name LIKE
regexp_replace('rob', '(%|_)', '\\\1', 'g') || '%';
I find it strange that there is no such functions shipped with PostgreSQL. Who wants their users to write their own patterns?
The best answer is that you shouldn't be interpolating user input into your sql at all. Even escaping the sql is still dangerous.
The following which uses go's db/sql library illustrates a much safer way. Substitute the Prepare and Exec calls with whatever your go postgresql library's equivalents are.
// The question mark tells the database server that we will provide
// the LIKE parameter later in the Exec call
sql := "SELECT * FROM users where name LIKE ?"
// no need to escape since this won't be interpolated into the sql string.
value := "%" + user_input
// prepare the completely safe sql string.
stmt, err := db.Prepare(sql)
// Now execute that sql with the values for every occurence of the question mark.
result, err := stmt.Exec(value)
The benefits of this are that user input can safely be used without fear of it injecting sql into the statements you run. You also get the benefit of reusing the prepared sql for multiple queries which can be more efficient in certain cases.
we are using oracle forms...
we have to protect (or) block a text item field from special charecters.
like ( !##$%^&*)
please send some guidences.... thanks in advance...
Regards,
Vijay
When your text box as some entered text you got to have a function that validates all input.
On that function you have a range off invalid values. That range is made in ASCII.
You can use format mask property like 999.99
Which version of forms?
Brute force method:
v_prohibited_chars VARCHAR2(100) := '!##$%^&*';
v_result VARCHAR2(4000);
...
-- strip prohibited characters
v_result := TRANSLATE(:form_field,'A'||v_prohibited_chars,'A');
-- if anything was stripped, lengths will differ
IF LENGTH(:form_field) <> LENGTH(v_result) THEN
error...
END IF
If I understand your comment correctly, you want to be able to filter the special character(s) out of the form field?
The above code does that, and places the result in v_result. So, if you have an input value of 'ABC#DEF#', and your filter mask is '!##$%^&*', then after executing TRANSLATE your result will be 'ABCDEF'. You can then reassign this value to your form field. If you just want to silently strip the character, you can skip the LENGTH checking and simply assign the output of TRANSLATE back to your form field:
:form_field := TRANSLATE(:form_field,'A'||v_prohibited_chars,'A');
What TRANSLATE does is check the characters in the first parameter against the characters in the second parameter. When it finds a match, it translates that character into the corresponding character in the third parameter. If no corresponding characters exist in the third parameter for one in the second, then the character is translated to NULL. If a character does not appear in the second parameter, it remains unchanged. So, the character 'A' is translated to 'A', and all of the other characters in the mask are translated to NULL. The third parameter cannot be NULL, hence the dummy translation of 'A' to 'A'.