This blog post shows an example of how to create a immutable_concat function in Pg:
CREATE OR REPLACE FUNCTION immutable_concat(VARIADIC "any")
RETURNS text AS 'text_concat'
LANGUAGE internal IMMUTABLE
I'd like to do the same with concat_ws and the corresponding text_concat_ws does exist, however, the following just crashes the process:
CREATE OR REPLACE FUNCTION immutable_concat_ws(VARIADIC "any")
RETURNS text AS 'text_concat_ws'
LANGUAGE internal IMMUTABLE
Update: The siguature of immutable_concat_ws should be (glue, *parts), one glue (text or varchar) and one or more parts (text, varchar or null).
What am I missing here?
Firstly, the function requires two parameters in the definition, like Richard already suggested, and you updated your question accordingly.
Secondly, you can create that function with "any" input using LANGUAGE internal. Does not mean that you should, though.
concat_ws() is only STABLE for a reason. Among others, the text representation of date or timestamp depends on locale / datestyle settings, so the result is not immutable. Indexes building on this could silently break. Restricted to text input, it's safe to declare it IMMUTABLE.
Since you only need text input (or varchar, which has an implicit cast to text), limit it to your use case and be safe:
CREATE OR REPLACE FUNCTION immutable_concat_ws(text, VARIADIC text[])
RETURNS text
LANGUAGE internal IMMUTABLE PARALLEL SAFE AS
'text_concat_ws';
Crating a LANGUAGE internal function requires superuser privileges. If that's not an option, the next best thing would be an SQL function like:
PostgreSQL full text search on many columns
Mark it as PARALLEL SAFE in Postgres 9.6 or later (it qualifies!) to enable parallelism when involving this function. The manual:
all user-defined functions are assumed to be parallel unsafe unless otherwise marked.
Resist the temptation to do things like this immutable_concat_ws('|', now()::text, 'foo'). This would reintroduce said dependencies in the call.
Related:
Combine two columns and add into one new column
OK, so you're mapping to internal "C" functions, which I must admit I've never done myself.
However, text_concat_ws is "with separator" so it doesn't just take a variadic list of text arguments - it takes a separator THEN the variadic list of text arguments. Adjust your function definition accordingly.
If you're going to be doing this, you probably want to hook a debugger up to the backend or run it single process if that's practical.
Also - I just found the doxygen interface to the PostgreSQL source-code replying to your question. Thanks :-)
Related
I am developing a netlogo extension and I want to add a command where the user will tell me a list of procedures names that have no parameters.
Later I will perform this procedures but the only thing I will know is the name of the procedure that was passed to me before.
The command that the user will use to inform the name of the procedures is the following:
qlearningextension:actions ["procedure1" "procedure2" "procedure3"]
Later the extension will perform this procedures. I want to know if there is a way to get a procedure with only having it's name.
My recommendation would be to change the syntax of your primitive from taking in a list of strings to taking in a repeatable number of anonymous commands. You can do this by setting the syntax to CommandType | RepeatableType. A good reference should be the ControlFlow extension (cf) which uses a similar technique to accept at least 1, but possibly many, boolean/command combinations for its variadic cf:iflese primitive.
The anonymous commands provided will be checked for correctness at compile time, meaning you won't have to rely on the extension user properly typing the name of the procedures or forgetting if they change a name. The commands will also be easily executable by your extension prim at runtime, you won't have to "search" for the right procedure to execute (again, see the cf example).
Users of your extension will need to wrap your prim in parens when using the "more than 1" repeatable syntax: (qlearningextension:actions [procedure1] [procedure2] [procedure3])
I use the following stored procedure to maintain the edit time on a few tables via triggers on those tables:
CREATE OR REPLACE FUNCTION maintain_edit_time()
RETURNS TRIGGER AS $t_edit_time$
BEGIN
NEW.edit_timestamp = NOW();
RETURN NEW;
END;
$t_edit_time$ LANGUAGE plpgsql;
When generating jOOQ objects for the database in question, I get the following generated code:
/**
* #deprecated Unknown data type. Please define an explicit {#link org.jooq.Binding} to specify how this type should be handled. Deprecation can be turned off using <deprecationOnUnknownTypes/> in your code generator configuration.
*/
#java.lang.Deprecated
public static Object maintainEditTime(Configuration configuration) {
MaintainEditTime f = new MaintainEditTime();
f.execute(configuration);
return f.getReturnValue();
}
/**
* #deprecated Unknown data type. Please define an explicit {#link org.jooq.Binding} to specify how this type should be handled. Deprecation can be turned off using <deprecationOnUnknownTypes/> in your code generator configuration.
*/
#java.lang.Deprecated
public static Field<Object> maintainEditTime() {
MaintainEditTime f = new MaintainEditTime();
return f.asField();
}
I assume this is because I do not have a jOOQ binding between TRIGGER and a Java object. However, I do not have a clue what I would define this binding as, nor do I have any need for a binding to exist.
Left alone, though, this generates a compile warning. What's the cleanest, easiest way to resolve this?
Options seem to include turning off deprecation, using ignoreProcedureReturnValues, or creating a binding. Ideally, I'd like to simply not generate a Java object for this procedure, but I could not find a way to do that.
Using ignoreProcedureReturnValues globally effects the project just because of this, which is fine for now, I don't have other procedures at all, much less others with a return value. But, I hate to limit future use. Also, I'm unclear one what the comment "This feature is deprecated as of jOOQ 3.6.0 and will be removed again in jOOQ 4.0." means on the jOOQ site under this flag. Is the flag going away, or is support for stored procedure return types going away? A brief dig through the jOOQ github issues didn't yield me an answer.
Tempted to simply turn off deprecation. This also seems like a global and not beneficial change, but it would serve the purpose.
If I created a binding, I have no idea what it would do, or how to define it since TRIGGER really isn't a sensible thing to bind a Java object to. I assume I'd specify as TRIGGER in the forcedType element, but then the Java binding seems like a waste of time at best and misleading at worst.
You've already found the perfect solution, which you documented in your own answer. I'll answer your various other questions here, for completeness' sake
Using ignoreProcedureReturnValues globally effects the project just because of this, which is fine for now, I don't have other procedures at all, much less others with a return value. But, I hate to limit future use. Also, I'm unclear one what the comment "This feature is deprecated as of jOOQ 3.6.0 and will be removed again in jOOQ 4.0." means on the jOOQ site under this flag. Is the flag going away, or is support for stored procedure return types going away? A brief dig through the jOOQ github issues didn't yield me an answer.
That flag has been introduced because of a backwards incompatible change in the code generator that affected only SQL Server: https://github.com/jOOQ/jOOQ/issues/4106
In SQL Server, procedures always return an INT value, just like functions. This change allowed for fetching this INT value using jOOQ generated code. In some cases, it was desireable to not have this feature enabled when upgrading from jOOQ 3.5 to 3.6. Going forward, we'll always generate this INT return type on SQL Server stored procedures.
This is why the flag has been deprecated from the beginning, as we don't encourage its use, except for backwards compatibility usage. It probably won't help you here.
Stored procedure support is definitely not going to be deprecated.
Tempted to simply turn off deprecation. This also seems like a global and not beneficial change, but it would serve the purpose.
Why not. A quick workaround. You don't have to use all the generated code. The deprecation is there to indicate that calling this generated procedure probably won't work out of the box, so its use is discouraged.
If I created a binding, I have no idea what it would do, or how to define it since TRIGGER really isn't a sensible thing to bind a Java object to. I assume I'd specify as TRIGGER in the forcedType element, but then the Java binding seems like a waste of time at best and misleading at worst.
Indeed, that wouldn't really add much value to your use cases as you will never directly call the trigger function in PostgreSQL.
Again, your own solution using <exclude> is the ideal solution here. In the future, we might offer a new code generation configuration flag that allows for turning on/off the generation of trigger functions, with the default being off: https://github.com/jOOQ/jOOQ/issues/9270
Well, after noting that an ideal way to do this would be to ignore that procedure, I did find how to ignore the procedure by name in the generally excellent jOOQ website documentation. Don't know how I missed in on first pass. If I needed to call this procedure in Java, I'm unclear which of the above options I would have used.
Luckily, there was no need for this procedure to be referenced in code, and I excluded it as shown below in in the jOOQ XML configuration.
<excludes>
databasechangelog.*
| maintain_edit_time
</excludes>
Postgres extension development
I am working with C API for postgres-9.4 installed from ubuntu trusty main repo. This might be a silly question, but please bear with me.
I would like to use a function that converts a cstring to Jsonb* structure defined in
http://doxygen.postgresql.org/jsonb_8h.html
There are functions doing exactly this already defined in
http://doxygen.postgresql.org/jsonb_8c.html
Namely, the function
Datum jsonb_in ( PG_FUNCTION_ARGS ), however I am not sure if I can call
this function from C API in a portable and safe manner. As it seems it is intended for being called by postgres from first glance.
I could also use the function jsonb_from_cstring
http://doxygen.postgresql.org/jsonb_8c.html#ab23eca28d5880f86a0943d71c90d6654
but it is declared and defined in jsonb.c and not declared in json.h, and hence linking with this function is not a very clean solution. I tried finding the symbols for jsonb_from_cstring in libpq.so, however there are none. I am guessing I need a non-standard build of postgres?
So the question is, what is the best way to convert a cstring to a Jsonb* structure from within C API?
Edit:
The extension gets json data as a string from external source and is supposed to be able to store this string in a Jsonb type
This was answered in postgres mailing list
http://www.postgresql.org/message-id/CAFj8pRCeGL7q_EGTz2=FyQZ2Qrtn1x_76mz3fuR=b7beEug7Wg#mail.gmail.com
Quote:
you can call "input function" - jsonb_in
Jsonb *targetjsonbvar = DatumGetJsonb(DirectFunctionCall1(jsonb_in,
CStringGetDatum(cstrvalue)));
PostgreSQL 9.2 has native JSON support. I'd like to store human readable config files, however, in YAML. And I think I'd like to index a few (but not all) of the config file values. Therefore I'm wondering:
Is it's somehow possible to include [a third party Javascript library that parses Yaml] in Postgres, for example js-yaml. Then I could have my own YAML Javascript helper, in the same way as there's the built-in JSON helper in PostgreSQL 9.2.
Alternatively:
is it possible to declare individual reusable Javascript functions? If so, then I could add my own YAML parsing functions (based on simple regexps), that are able to parse a subset of YAML, for example the top level key-value pairs here:
# some "top level key-value paris":
the_key: 'the value'
another_key: 'another value'
# But this however:
would_be_too_complicated_to_parse_manually_with_regexps: |
block string
with newlines
Worst case scenario would be that I'd need to duplicate YAML parsing code in each PostgreSQL stored procedure (if I cannot add 3rd party libraries or declare reusable functions).
(Performance wouldn't be terribly important in my case.)
(I've googled a while for "postgresql plv8 reusable function" and "postgresql plv8 library" but found nothing of relevance)
The pl/v8 procedural language is probably the way to go. It's a 'trusted' language, which means (among other things) it does not provide any way to do the 'load an external module from this file' thing. But it does have a 'find_function()' method to let you define your own javascript function and call it from another function (js or not). See description of it in this blog post:
http://umitanuki.hatenablog.com/entry/2012/04/10/171935
Ruby has this very interesting functionality in which when you create a class with 'Class.new' and assign it to a constant (uppercase), the language "magically" sets up the name of the class so it matches the constant.
# This is ruby code
MyRubyClass = Class.new(SuperClass)
puts MyRubyClass.name # "MyRubyClass"
It seems ruby "captures" the assignment and inserts sets the name on the anonymous class.
I'd like to know if there's a way to do something similar in Lua.
I've implemented my own class system, but for it to work I've got to specify the same name twice:
-- This is Lua code
MyLuaClass = class('MyLuaClass', SuperClass)
print(MyLuaClass.name) -- MyLuaClass
I'd like to get rid of that 'MyLuaClass' string. Is there any way to do this in Lua?
When assigning to global variables you can set a __newindex metamethod for the table of globals to catch assignments of class variables and do whatever is needed.
You can eliminate one of the mentions of MyLuaClass...
> function class(name,superclass) _G[name] = {superclass=superclass} end
> class('MyLuaClass',33)
> =MyLuaClass
table: 0x10010b900
> =MyLuaClass.superclass
33
>
Not really. Lua is not an object-orientated language. It can behave like one sometimes. But far from every time. Classes are not special values in Lua. A table has the value you put in it, no more. The best you can do is manually set the key in _G from the class function and eliminate having to take the return value.
I guess that if it REALLY, REALLY bothers you, you could use debug.traceback(), get a stack trace, find the calling file, and parse it to find the variable name. Then set that. But that's more than a little overkill.
With respect at least to Lua 5.2: You can capture assignments to A) the global table of a Lua State, as mentioned in a previous reply, and also B) to any other Lua Object whose __index and __newindex metamethods have been substituted (by replacing the metatable), this I can confirm as I'm currently using both these techniques to hook and redirect assignments made by Lua scripts to external C/C++ resource management.
There is a gotcha with regards to reading them back though, the trick is to NOT let the values be set in a Lua State.
As soon as they exist there, your hooks will fail to be called, so if you want to go down this path, you need to capture ALL get/set attempts, and NEVER store the values in a Lua State.