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.
I'm using plpython3u to process a result that contains an arbitrary number of columns each of which hold an array (of varying lengths > 0). In python, I'd be expecting to process this data as a multidimensional array but I'm having trouble getting it from Postgres into my function.
The function declaration I am using looks like this:
CREATE OR REPLACE FUNCTION is_set_cover_possible(VARIADIC args numeric[][])
The problem is that when I try
SELECT is_set_cover_possible(ARRAY[1,2],ARRAY[1,2]);
I get:
No function matches the given name and argument types. You might need to add explicit type casts.
If I pass in (ARRAY[1,2]) the function returns a result without failing so it seems postgres can't handle the multidimensional declaration above.
So, if it's actually possible: How do I declare the function so as to receive a list of arrays?
You cannot to do it. Arguments used as variadic arguments cannot be arrays.
Implementation of variadic arguments was at time when this was not possible technically. Now it is possible, but nobody implemented it.
In Javascript you can use the spread syntax in a function call like this:
console.log(...[1,2,3]);
Is there an equivalent in Reason? I tried the following:
let bound = (number, lower, upper) => {
max(lower, min(upper, number));
};
let parameters = (1,0,20);
bound(...parameters) |> Js.log;
But this gives an unknown syntax error:
Try reason snippet
There's not. Reason is a statically typed language, and lists are dynamically-sized and homogenous. It would be of very limited use, and not at all obvious how it would deal with too few or too many arguments. If you want to pass a list, you should just accept a list and deal with it appropriately, as a separate function if desired.
You could of course use a tuple instead, which is fixed-size and heterogenous, but I don't see a use-case for that either, since you might as well just call the function directly then.
For JavaScript FFI there is however the bs.splice attribute, which will allow you to apply a variable number of arguments to a js function using an array. But it needs to be called with an array literal, not just any array.
In PostgreSQL when I call NUMERIC(10,2) to define a variable type. Which part of the PostgreSQL C code is handling it?
I am interested in knowing where the precision and scale are handled.
Lots of parts.
The lexer and parser transforms it into a type name and type modifier.
The system catalogs and syscache look up numeric to find the matching type oid.
The numeric.c code handles the actual type input/output and operators, and interprets the type modifier.
The index access methods and index operator classes handle selection of operators for comparisons etc.
I'm trying to use Matlab's inputParser for the first time, and I have to say I'm finding it a bit confusing. I am unable to successfully provide an anonymous function as an optional parameter.
This is the function I am passing arguments to
function myfun(str,bounds,varargin)
p = inputParser;
p.FunctionName = mfilename;
p.addRequired('str',#isstr);
p.addRequired('bounds',#isvector);
p.addOptional('str_latex','',#isstr);
p.addOptional('seed',[], #(x) isa(x,'function_handle'))
p.parse(str,bounds,varargin{:});
p.Results
% do something here
end
And I am calling it like this...
myfun('str', 'epsilon',...
'str_latex', '\epsilon',...
'bounds', [0 1],...
'seed', #() betarnd(2,2))
But I get an error:
Error using my fun
The value of 'seed' is invalid. It must satisfy the function: #(x)isa(x,'function_handle').
I suspect a simple error, but I cannot figure it out.
Name-value pairs are declared using the addParameter method (R2013b+, addParamValue prior to that). addRequired and addOptional do not have name-value pairs associated with them, simply identifying/documenting argname inputs for internal use and association with the parsed struct. It appears you want to use all addParamter-s in this use case.
The main idea behind the three input types is
Required: the very first arguments with explicit, documented inputnames that absolutely need to be supplied by the user for the function to perform properly.
Optional: arguments that typically follow Required arguments with explicit, documented inputnames that are often input by the user for customized behavior.
Name-Value: arguments that typically follow Optional arguments with a name specifying the value to be set are often input by the user for customized behavior but not so often as to be given an upfront, explicit parameter like Optional arguments.
In my experience, Required arguments are almost always obvious, for good, well-defined functions, while Optional and Name-Value is more experience-, complexity-, and aesthetics-based. A simple example would be linspace: the start and end of the interval are absolutely needed for the function to work, but not necessarily the number of points which can be left to 100 by default, but giving it an explicit name-value pair is a little overkill. A more complex example would be the plot function: at a minimum y data is needed, then x,y pairs of data, then x,y,linSpec sets of data, and then a whole list of specific name-value pairs for pinpoint customization that users can use if they so choose.
With your input parser as written, the call sequence should be:
myfun('epsilon',[0,1],'\epsilon',#() betarnd(2,2));
Since no name-value pairs were declared, none exist, but the Optional arguments still have a positional order associated with them. You can re-write your parser as:
function myfun(varargin)
p = inputParser;
p.FunctionName = mfilename;
p.addParameter('str',[],#isstr);
p.addParameter('bounds',[],#isvector);
p.addParameter('str_latex','',#isstr);
p.addParameter('seed',[], #(x) isa(x,'function_handle'))
p.parse(str, bounds, varargin{:});
p.Results
% do something here
end
For something like the generic input sequence you may have been expecting. Notice that I used []-s to fail the simple validations without a good error message; you should add a good error message indicating that those name-value pairs are required for proper functionality, or do as you were doing and have explicit, upfront Required inputs with addRequired but without the name-value semantics.