On 06/27/2018 07:36 PM, Nikita Glukhov wrote:
> Also it can be found in our sqljson repository on sqljson_doc branch:
> https://github.com/postgrespro/sqljson/tree/sqljson_doc
Perhaps it is my unfamiliarity, but it seems that on lines 1067–1071,
the output clause for JSON_VALUE is given support for return types
json, jsonb, bytea, text, char, varchar, nchar "out of the box".
There are then examples on lines 1123–1135 of returning float, int,
and date.
Does that mean that the list in 1067–1071 is incomplete, and should
include additional data types?
Or does it mean that there is more cleverness buried in the
"must ... have a cast to the specified type" language than I
first understood?
Does the function support returning some wanted type w, not in the
out-of-the-box list, such as float, by searching for an intermediate
type t ∈ {json, jsonb, bytea, text, char, varchar, nchar} such that
∃ cast(t as w), then representing the JSON value as t, then casting
that to w ?
If so, what does it do if more than one t is a candidate?
Line 2081: "A typical path expression has the following structure"
It seems like a "weasel word" to have "typical" in the statement
of an expression grammar. Is there more to the grammar than is
given here?
Lines 2323 and 2330 ( / and % operators ). Do these behave differently
for integer than for float operands? If they provide integer operations,
which results do they produce for negative operands? (A recent minor
trauma reminded me that C before C99 left that unspecified, but as this
is a special-purpose language, perhaps there is a chance to avoid
leaving such details vague. :) For a similar-language example,
XPath/XQuery specifies that its idiv and mod operators have the
truncate-quotient-toward-zero semantics, regardless of the signs of
the operands.
Line 2519, like_regex: What regex dialect is accepted here? The same
as the PostgreSQL "POSIX regex"? Or some other?
This looks like very interesting functionality!
-Chap