How to remove configuration parameter - postgresql

In Postgres it is possible to create your own configuration parameters, something like a "cookie" that persists for duration of either session or transaction.
This is done like that:
SELECT set_config(setting_name, new_value, is_local)
or
SET [ SESSION | LOCAL ] configuration_parameter { TO | = } { value | 'value' | DEFAULT }
Local is supposed to persist only for duration of transaction, but it does affect configuration parameter even after transaction - instead of said parameter being unrecognized, it will be now set to empty string.
Question
How to make said parameter unrecognized again, without reconnecting?
This does not work:
SELECT set_config('settings.myapp.value', null, true);
RESET settings.myapp.value;
This will not return NULL, instead it gives empty string:
SELECT current_setting('settings.myapp.value', true);
I can of course work around this, but I would like to know if I can somehow revert state of configuration parameter back to what it was before "transaction only" change.
SELECT nullif(current_setting('settings.myapp.value', true), '');

You cannot do that.
If you create a new parameter, it is created as a “placeholder” parameter.
If you later load a module that defines that parameter, it will be converted to a “real” parameter on the fly.
But there is no way to delete a parameter during the lifetime of a database session.

Related

Prisma not performing update on record

There are a few things going on with Prisma update that I just don't get.
Why is the update (using the ORM way) not performed ?
Why the value of data.address seems to affect the outcome of the update ?
Do I have to provide all of the fields of the entity when updating ? Or in this case, could I just put what I want changed inside of data ?
I am using #prisma/client#3.15.2
Here is what I am currently working with:
const { valid: validFor, expire, state, address, ...safeProperties } = data;
const addressAsUnsigned = address >>> 0; // address is an ip address represented as an integer. It needs to be treated as unsigned
const extendBy = newValidFor - validFor;
const extended = add(expire, { seconds: extendBy });
const payload: Prisma.DataTableUpdateArgs = {
where: { address: addressAsUnsigned },
data: {
...safeProperties,
address: addressAsUnsigned,
expire: extended,
valid: authenticated,
state: {},
},
}
Logger.debug(payload);
// contains the changes I expect
const result = await db.dataTable.update(payload);
Logger.debug(result);
// result contains the same values as before the update.
// And indeed, when I check the database, nothing changed.
// Something like this does what I want, so there is really nothing complicated going on...
await db.$executeRaw`
UPDATE data_table SET
expire = ${extended},
valid = ${authenticated}
WHERE address = ${addressAsUnsigned}
`;
Hopefully, I have not missed something too obvious.
In my experience,
Why is the update (using the ORM way) not performed ?
You might be updating the wrong thing. Is your address an #unique field in your prisma.schema?
Why the value of data.address seems to affect the outcome of the update ?
Prisma might have messed some things up with wrong data. If your data is not unique, you might be updating the first row with that address. If you want to update multiple fields with same address, use updateMany
Do I have to provide all of the fields of the entity when updating ? Or in this case, could I just put what I want changed inside of data ?
No, you only need to put in the data that you need. In your "where" field, add the unique address, and in your data, only the fields that you are changing. In your case, expired and valid. If you want to skip updating some values, use "expired: undefined" and so on
Since you are using typescript, I would advise you to put your object directly inside the prisma update to get the correct types. (At least to fix this problem)
prisma.dataTable.update({where: {...}})
This way you will get the correct types. There is also a command to list all available args inside (control + space on mac)
Note that using the spread operator (...) will remove the listed types, so use it last.
Some other things: double check if your prisma import is correct. Is your data correct, is your returned data correct? Did you refresh your database on update? It might be updated but you just need to refresh for new changes.

How do reset groupFirstKey QueueConfiguration field to default value (null) via ActiveMQServerControl.updateQueue(String queueConfiguration)

I created a queue via the method ActiveMQServerControl.createQueue(String queueConfiguration) with a value for the groupFirstKey.
How to reset groupFirstKey field of QueueConfiguration this queue to default value (null) via ActiveMQServerControl.updateQueue(String queueConfiguration)?
If I set "" for groupFirstKey in the String queueConfiguration (for example {"name":"MAXC","address":"MAXC","routing-type":"ANYCAST","group-first-key":""}), then for the groupFirstKey value I get not null, but "", respectively.
Currently there is no way to do this via the management interface (i.e. using the ActiveMQServerControl) because ActiveMQServerControl.updateQueue(String queueConfiguration) ultimately performs a check on the members of the JSON input that is passed in, and any members that are null (i.e. don't exist) are not updated.
However, if you're using an embedded server then you can use the updateQueue(QueueConfiguration, boolean) method directly on org.apache.activemq.artemis.core.server.ActiveMQServer and pass true for the boolean to force any null parameters to be used for the update.

How to unset (remove,not reset) a custom config parameter?

I am using set_config to set some context on the session (i.e user context).
Once I set the context for a parameter - I can't seem to get rid of it. RESET/SET param TO DEFAULT will empty the value but not remove it altogether.
select current_setting('my.test1'); -- SQL Error [42704]: ERROR: unrecognized configuration parameter "my.test1"
select set_config('my.test1','123',false);
select current_setting('my.test1'); -- returns 123
set my.test1 to default; --same as reset my.test1
select current_setting('my.test1'); --returns an empty string rather than an exception
How to remove it (raise exception again) ?
I am catching 42704 but it won't be thrown if I just "reset" it.
p.s I assume pg_reload_conf might help - but it seems too aggressive for this simple task.
Thanks.
The answer is that you cannot (in postgres 10), if you are in the same session.
Those empty parameters ONLY go away if you exit the session and open a new session. pg_reload_conf() has no effect on the custom variables that have been set in a session, or local to a transaction, and doesn't work to remove the parameter. They just stay as '' ... empty string.
For me this is a very legitimate question and issue also ...
i have been finding the same behaviour with custom ( ie name_one.name_two ) configuration parameters, whilst i've been developing a configuration setting wrapper to overlay into individual schemas.
Once the parameter has been set locally with eg set_config ( _name_ , _value_ , TRUE ) OR at session level with set_config ( _name_ , _value_ , FALSE) ... it is not removed if set to NULL or UNSET or to DEFAULT ... there is no way around this i have found, after testing and testing and questioning my own perception of my slightly nested functions and scoping ... and so my only answer has been to alter one of my pure SQL language functions to PLPGSQL and make a test for the particlular parameter that i was relying on as being not existing, because my call that allows missing_ok : current_setting ( '_pre._global_int_' , TRUE )does not return NULL if at some point earlier in any transaction in the session it has been set locally or not locally !!!
It had been frustrating me also, and i was very happy to find that this question had already been asked, and so here i give the answer :
it cannot be done in the same session in PG 10
( i have not tried it yet in 11 or 12 or 13 )
UPDATE :
i just found this answer, https://stackoverflow.com/a/50929568/14653862, of Laurenz Albe, which also says that in the same session you cannot

Powershell Replace fail after test for null

I'm pulling data from a database (access specifically using ADO). Then I am preparing the variable for possible insertion into SQL later by replacing any existing single quotes with two single quotes.
Because the value coming from the database is very likely to be null, I test for it and the replace is only supposed to happen if it is NOT null. The value I'm getting it not registering as null when I test it, but when I try the replace, I get the error
Method invocation failed because [System.DBNull] does not contain a method named 'Replace'.
Here's the section of code $OldAbstract = $rs.Fields.Item("MetaAbstract").value
if($OldAbstract -ne $null) {$OldAbstract = $OldAbstract.Replace("'","''")}
After pulling the value, I print it and it looks like nothing. I tested it for null, and it says it's not. I tested it for "" and it's not. I even checked to see if it was a space, and it's not. The length is reported as 1... I'm at a loss as to what's going on.
You're testing for the wrong type of null - PowerShell/.net null instead of a database null. Try this (untested):
$OldAbstract = $rs.Fields.Item("MetaAbstract").value
if($OldAbstract -isnot [System.DBNull]) {$OldAbstract = $OldAbstract.Replace("'","''")}

Enter a query in a default value expression

In Jasperreports I would like to enter a Default Value Expression to a Parameter as a Query string to be able to dynamically provide the user with a default value that is correct, but not force him to choose it.
Is there anyway?
I guess the result should look something like this (even though it doesn't work):
I am using this for a form with a single-value selection method (the user can write which ever number he/she wants but I want the default value to be selected from the database).
Here's how I handle this:
The user selects a value from an input control (in my example, I will call it $P{time_toggle}). Then, I have another parameter ($P{time_constraint}) that takes the user input from $P{time_toggle} and decides what SQL string to inject into the main query based on it. The default value expression for $P{time_constraint} looks like:
$P{time_toggle} == "rolling_quarter" ? "..." : (
$P{time_toggle} == "rolling_30_days" ? "..." : (...
)
)
Then, in my main report query I reference $P{time_constraint}:
SELECT * FROM tblTable WHERE $P!{time_constraint}
To set a default time period, I set the default value expression for $P{time_toggle} to my desired default.