how can we design the string pattern if i want to allow special characters (##$%) also to be included in the value for Name.
For Ex. All the below ones are valid entries for Name
Name = aaa990ZX
Name = a##9980XS
Name = $$$$$$$$
Name = 00000000
typedef Name {
type string {
pattern [a-zA-Z0-9];
}
description
"Value " ;
}
YANG uses the XSD schema regular expression flavor to define such constraints. Simply define and expression such as:
pattern '[a-zA-Z0-9##$%]+';
It is recommended to use a single quote string to define a YANG pattern statement argument in order to avoid escape sequence problems.
The exact specification of acceptable regular expressions may be found here.
I suggest you read up on regular expressions and perhaps look for a tutorial on it.
Related
The example in a section about 'list context' in the polars-book uses pl.col("") expression with an empty string "" as the argument.
# the percentage rank expression
rank_pct = pl.col("").rank(reverse=True) / pl.col("").count()
From the context and the output I can guess what pl.col("") expression does. But the API documentation does not seem to cover a case of empty string as the argument to pl.col and I would like to know the precise meaning in this use case. Any helpful answer is greatly appreciated!
The precise meaning is to act as a 'root' Expression to start a chain of Expressions inside a List context, i.e., inside arr.eval(....). I'll need to take a step back to explain...
'Root' Expressions
In general, only certain types of Expressions are allowed to start (or be the 'root' of) an Expression. These 'root' Expressions work with a particular context (select, filter,with_column, etc..) to identify what data is being addressed.
Some examples of root Expressions are polars.col, polars.apply, polars.map, polars.first, polars.last, polars.all, and polars.any. (There are others.)
Once we declare a "root" Expression, we can then chain other, more-generic Expressions to perform work. For example, polars.col("my_col").sum().over('other_col').alias('name').
The List context
A List context is slightly different from most contexts. In a List context, there is no ambiguity as to what data is being addressed. There is only a list of data. As such, polars.col and polars.first were chosen as "root" Expressions to use within a List context.
Normally, a polars.col root Expression contains information such as a string to denote a column name or a wildcard expression to denote multiple columns. However, this is not needed in a List context. There is only one option - the single list itself.
As such, any string provided to polars.col is ignored in a List context. For example, from the code from the Polars Guide, this code also works:
# Notice that I'm referring to columns that do not exist...
rank_pct = pl.col("foo").rank(reverse=True) / pl.col("bar").count()
Since any string provided to a polars.col Expression will be ignored in a List context, a single empty string "" is often supplied, just to prevent unnecessary clutter.
Edit: New polars.element expression
Polars now has a polars.element expression designed for use in list evaluation contexts. Using polars.element is now considered idiomatic for list contexts, as it avoids confusion associated with using col(“”).
Reading the PostgreSQL docs, I see that you can cast a longish bit of text to xml like this:
SELECT xml '<long>long text, may span many lines</long>'
SELECT xml '...'
Curious, I found that I could do the same with JSON:
SELECT json '{"arg1":"val1", <more args spanning many lines>}'
(I couldn't find an official reference for this one. It just works!)
By contrast, this does not work:
SELECT float8 3.14159
I like this alternate syntax from a readability perspective. Now I'm looking for a reference listing which types may be specified up front like this. but I haven't found it yet.
Any pointers?
The documentation says:
A constant of an arbitrary type can be entered using any one of the following notations:
type 'string'
'string'::type
CAST ( 'string' AS type )
The string constant's text is passed to the input conversion routine for the type called type. The result is a constant of the indicated type. The explicit type cast can be omitted if there is no ambiguity as to the type the constant must be (for example, when it is assigned directly to a table column), in which case it is automatically coerced.
The form you are asking about is the first one.
So this can be used for all PostgreSQL types.
Note that the data must be specified as a string literal (in single or dollar quotes) when you use that syntax.
this is my example to show you the problem I need to call two rules
generate umlDsl "http://www.xtext.org/example/umldsl/UmlDsl"
Model:
elements+=rule*
;
rule:
rul1 'and' rul2
;
rul1:
'rul1' action1=[uml::Action|FQN]
;
rul2:
'rul2' action2=[uml::Action|FQN]
;
FQN returns ecore::EString:
ID ("." ID)*
;
I have this error
Multiple markers at this line (rul1 'and' rul2)
An unassigned rule call is not allowed, when the 'current'
was already created.
Cannot change type twice within a rule
I want to know why I have this error and how to fix it please
These errors occurs because of your rule implementation of rule rule
rule:
rul1 'and' rul2
;
As I understand rule has two attributes, rul1 and rul2. But in your implementation rule does not have any attributes. To define rul1 and rul2 as attribuites you have assign these elements to an attribute. This could look like this:
rule:
rul1=rul1 'and' rul2=rul2
;
Have you looked into the Xtext documentation [1] to learn about the grammar language syntax and semantics?
The things you need to know for understanding your error are the following:
An attribute of a parser rule needs a name. To this name you assign a value, which is an other parser rules name. It is similar to assing values to a field in Java:
int i = 42;
A field declaration consists of the fields type (int) and the fields name (i) this normally is followd by the assignment operator (=) and the value (42). The attribute definiton of a parser rule follows this scheme:
RuleA: 'some syntax' attributeName=OtherRule 'more syntax';
OtherRule: 'other syntax' attribute=NextRule ... ;
...
A parser rule in Xtexts grammar language is like a Java class. RuleName corresponds to class ClassName. Then you can define some static syntax with 'keyword'. If any other rule should occur within any other rule, it can be understood as a field declaration. This rule is an attribute which is implemented like this:
attributeName=AnyRule
Where attributeName corresponds to the field name. But to an attribute the type of the value is assigned (AnyRule).
Btw. I strongly recommand that rule names should start with an Capital letter and attribute names should start with an lower case letter.
[1] https://www.eclipse.org/Xtext/documentation/301_grammarlanguage.html
I have built User Define Type with function_in and function_out.
CREATE OR REPLACE FUNCTION MyOwnType_in(cstring)
RETURNS MyOwnType
AS '/home/postgres/ENCRIPTION/MyOwnType/MyOwnType.so','MyOwnType_in'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION MyOwnType_out(MyOwnType)
RETURNS cstring
AS '/home/postgres/ENCRIPTION/MyOwnType/MyOwnType.so','MyOwnType_out'
LANGUAGE C IMMUTABLE STRICT;
As you can see each function_in receives cstring and function_out returns cstring.
The thing is function overloading and operator overriding on which I don't want to waste my time.
Is there any way to declare DEFAULT TYPE for my MyOwnType type which tells postgres that functions and operators with MyOwnTypearguments can parse and rewrite it into text?
The most you can do with your type is to mark it as a string type, with:
CREATE TYPE MyOwnType(
INPUT = MyOwnType_in,
OUTPUT = MyOwnType_out,
CATEGORY = 'S'
-- ...
);
The category parameter is especially useful when adding a user-defined type to an existing built-in category, such as the numeric or string types. However, it is also possible to create new entirely-user-defined type categories. Select any ASCII character other than an upper-case letter to name such a category ...
It may require additional CASTs, as #IgorRomanchenko suggested.
You need to CREATE CAST ... AS IMPLICIT from your datatype to text. This way your type will be automatically cast to text when a function/operator requires text.
Details here: http://www.postgresql.org/docs/current/static/sql-createcast.html
I just found some scala code which has a strange class name:
class `This is a cool class` {}
and method name:
def `cool method` = {}
We can use a sentence for a class or method name!
It's very cool and useful for unit-testing:
class UserTest {
def `user can be saved to db` {
// testing
}
}
But why we can do this? How to understand it?
This feature exists for the sake of interoperability. If Scala has a reserved word (with, for example), then you can still refer to code from other languages which use it as a method or variable or whatever, by using backticks.
Since there was no reason to forbid nearly arbitrary strings, you can use nearly arbitrary strings.
As #Rex Kerr answered, this feature is for interoperablility. For example,
To call a java method,
Thread.yield()
you need to write
Thread.`yield`()
since yield is a keyword in scala.
The Scala Language Specification:
There are three ways to form an identifier. First, an identifier can
start with a letter which can be followed by an arbitrary sequence of
letters and digits. This may be followed by underscore ‘_’ characters
and another string composed of either letters and digits or of
operator characters. Second, an identifier can start with an operator
character followed by an arbitrary sequence of operator characters.
The preceding two forms are called plain identifiers. Finally, an
identifier may also be formed by an arbitrary string between
back-quotes (host systems may impose some restrictions on which
strings are legal for identifiers). The identifier then is composed of
all characters excluding the backquotes themselves.
Strings wrapped in ` are valid identifiers in Scala, not only to class names and methods but to functions and variables, too.
To me it is just that the parser and the compiler were built in a way that enables that, so the Scala team implemented it.
I think that it can be cool for a coder to be able to give real names to functions instead of getThisIncredibleItem or get_this_other_item.
Thanks for your questions which learnt me something new in Scala!