I can't understand this:
[lsort [::array names my_array *,dut_inst]]
What meaning of * ?
What meaning of dut_inst ?
Where can I read about it ?
Let's assume:
my_array(0)=0
my_array(1)=1
my_array(2)=2
What will I get ?
That optional argument to array names is an optional glob pattern that is used to filter the results to return down to a subset. The rules for how it works are described in the documentation for string match, but in the case of *,dut_inst we have two parts:
* matches any number of characters.
,dut_inst is literal (as none of the characters in it are special in the string match rules).
The effect is to return a list of all element names whose names end with ,dut_inst. With your sample data, you get an empty list. With this sample data:
my_array(foo,bar)=1
my_array(boo,dut_inst)=2
my_array(dut_inst,grill)=3
my_array(abc,dut_inst,def)=4
my_array(pqr,dut_inst)=5
You'd get this output (assuming the lsort is there; Tcl does not guarantee the order of array iteration): boo,dut_inst pqr,dut_inst
Related
In my sql code, I receive a input string as a regular match's filter, I want to have the whole string as a normal string, even it includes some special characters.
Just look below:
do $$ declare
jdata jsonb='[{"name":"Dog 3*240+1*120"}]'::jsonb;
vfilter1 text='dog';
vfilter2 text='3*240+1*120';
vexists bool=false;
begin
select jdata #? concat('$[*] ? (#.name like_regex "',vfilter1,'" flag "i")')::jsonpath into vexists;
raise notice 'exists:%',vexists; --the result is true
select jdata #? concat('$[*] ? (#.name like_regex "',vfilter2,'" flag "i")')::jsonpath into vexists;
raise notice 'exists:%',vexists;-- the result is false
end;
$$ language plpgsql;
the string 3*240+1*120 include + and * characters, perhaps this causes the regular match have them as special character. In my code, I just want to have the whole vfilter string includes all special characters together as a normal string for the regular match.
What should I do?
You should read the documentation for the feature you are using.
The optional flag string may include one or more of the characters i
for case-insensitive match, m to allow ^ and $ to match at newlines, s
to allow . to match a newline, and q to quote the whole pattern
(reducing the behavior to a simple substring match).
First week having to deal with a MYSQL database and JSON field types and I cannot seem to figure out why values are encoded automatically and then returned in encoded format.
Given the following SQL
-- create a multiline string with a tab example
SET #str ="Line One
Line 2 Tabbed out
Line 3";
-- encode it
SET #j = JSON_OBJECT("str", #str);
-- extract the value by name
SET #strOut = JSON_EXTRACT(#J, "$.str");
-- show the object and attribute value.
SELECT #j, #strOut;
You end up with what appears to be a full formed JSON object with a single attribute encoded.
#j = {"str": "Line One\n\tLine 2\tTabbed out\n\tLine 3"}
but using JSON_EXTRACT to get the attribute value I get the encoded version including outer quotes.
#strOut = "Line One\n\tLine 2\tTabbed out\n\tLine 3"
I would expect to get my original string with the \n \t all unescaped to the original values and no outer quotes. as such
Line One
Line 2 Tabbed out
Line 3
I can't seem to find any JSON_DECODE or JSON_UNESCAPE or similar functions.
I did find a JSON_ESCAPE() function but that appears to be used to manually build a JSON object structure in a string.
What am I missing to extract the values to the original format?
I like to use handy operator ->> for this.
It was introduced in MySQL 5.7.13, and basically combines JSON_EXTRACT() and JSON_UNQUOTE():
SET #strOut = #J ->> '$.str';
You are looking for the JSON_UNQUOTE function
SET #strOut = JSON_UNQUOTE( JSON_EXTRACT(#J, "$.str") );
The result of JSON_EXTRACT() is intentionally a JSON document, not a string.
A JSON document may be:
An object enclosed in { }
An array enclosed in [ ]
A scalar string value enclosed in " "
A scalar number or boolean value
A null — but this is not an SQL NULL, it's a JSON null. This leads to confusing cases because you can extract a JSON field whose JSON value is null, and yet in an SQL expression, this fails IS NULL tests, and it also fails to be equal to an SQL string 'null'. Because it's a JSON type, not a scalar type.
When practicing with Octave I created a variable with the name my_name = ["Andrew"] and upon asking Octave to interpret whether it was a string it outputted a '0'. Again when using the typeinfo(my_name) I got ans = string. Why am I getting this sort of output?
octave:47> my_name = ["Andrew"]
my_name = Andrew
octave:48> isstring(my_name)
ans = 0
octave:49> typeinfo(my_name)
ans = string
According to the documentation (emphasis mine):
isstring (s)
Return true if s is a string array.
A string array is a data type that stores strings (row vectors of characters) at each element in the array. It is distinct from character arrays which are N-dimensional arrays where each element is a single 1x1 character. It is also distinct from cell arrays of strings which store strings at each element, but use cell indexing ‘{}’ to access elements rather than string arrays which use ordinary array indexing ‘()’.
Programming Note: Octave does not yet implement string arrays so this function will always return false.
That is, isstring will always return false (or 0), no matter what the input is.
You should use ischar to determine if the input is a character array (==string).
What does %%%s%% mean? Also what does `%(author) mean?
cursor.execute("SELECT * FROM new WHERE author LIKE '%%%s%%' "%(author)
In a SQL LIKE pattern, % matches any sequence of characters. So if you write:
WHERE author LIKE '%Jones%'
it will match an author that contains Jones anywhere in it.
This code is also using the Python % operator for string formatting, that's what %(author) is for. This formatting operator looks for formatting specifications in the string that begin with % -- %s means to substitute the value of the corresponding string from the tuple (author).
And since % has special meaning in the format string, you need to double it to produce a literal % character.
So if you do:
author = "Jones"
then the value of
"SELECT * FROM new WHERE author LIKE '%%%s%%' "%(author)
will be:
"SELECT * FROM new WHERE author LIKE '%Jones%'"
While using Tcl, as mentioned in the documentation here, shouldn't the following code,
string match h* match
, return 1 for the matched h character in "match" instead of what it actually returns , that is, 0 ?
In the same page itself you have the following content,
# Matches
string match f* foo
# Matches
string match f?? foo
# Doesn't match
string match f foo
The match is applied as if a whole word, not like string contains that particular word.
With string match h* match, it will try to match a pattern whose first letter is h and further zero or more occurrence of any string of characters, which is not true for word match.
Instead, you can rely on regexp for what you expect to happen.
# Matches, will return 1
regexp h* match