I have some SQL statements that cause this to happen:
NOTICE: word is too long to be indexed
DETAIL: Words longer than 2047 characters are ignored.
What's the easiest way to not have these notices be generated in the first place? (It's a long story why I'd want to do it that way.)
An example of such a statement is this:
update rev set html = regexp_replace(html,
'***=<a href="' || old.url || '">',
'<a href="' || new.url || '">',
'gi')
where id in (
select id
from rev
where to_tsvector('tags_only', html) ##
plainto_tsquery('tags_only','<a href="' || old.url || '">')
)
It's not the A tags with long urls or anything causing the problem. It's probably embedded CDATA-style graphics. I don't care that they're not indexed, whatever they are. I just want these notices to not occur.
If you don't mind suppressing all notices just change PostgreSQL error reporting level. client_min_messages defines lowest level of error/warning/notice messages sent to client, log_min_messages does the same for messages saved in log. Possible values are: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, PANIC
edit:
Disable for this query only: SET LOCAL client_min_messages TO WARNING;
Disable for this session only: SET SESSION client_min_messages TO WARNING;
Disable for this user: ALTER ROLE username SET client_min_messages TO WARNING;
Related
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
In this wonderful answer is proposed GUC-pattern to use run-time parameters to detect current user inside trigger (as one solution). It seemed to suit to me too. But problem is: when I declare the variable in postgresql.conf it is usable inside trigger and I can access it from queries, but can't change it:
# SET rkdb.current_user = 'xyzaaa';
ERROR: syntax error at or near "current_user"
LINE 1: SET rkdb.current_user = 'xyzaaa';
The error message is misleading, so I did not dig it a while, but now it seems this user (database owner) has no permissions to change params set in global configuration.
I can set any other params:
# SET jumala.kama = 24;
SET
And read it back:
# SHOW jumala.kama;
jumala.kama
-------------
24
(1 row)
I can't SHOW globally set params:
# SHOW rkdb.current_user;
ERROR: syntax error at or near "current_user"
LINE 1: SHOW rkdb.current_user;
^
but I can reach it with current_setting() function:
# select current_setting('rkdb.current_user');
current_setting
-----------------
www
(1 row)
So my guess is, my database owner does not have permissions to access this param. How could I:
set needed permissions?
or even better
set run-time params with database owner rights?
current_user is an SQL standard function, so your use of that name confuses the parser.
Either use a different name or surround it with double quotes like this:
rkdb."current_user"
Can I turn case-sensitive data handling from Vertica off session wise . I want it to be dependent on user who may either want to keep it case-sensitive or otherwise !
Also Is there any key to be modified while logging in to mark the session on for Unicode data handling ?
There are indeed ways. I did not test them fully, so there might be corner cases I am not aware of. The keyword you are looking for is collation. You specifically want to update the colstrength keyword and you want a value of 1 I believe (case and accents are ignored).
You can do it in a few ways:
vsql-only : \locale en_US#colstrength=1
from anywhere including via ODBC/JDBC statements: SET LOCALE TO 'en_US#colstrength=1';
by overriding the Locale value in your DSN (not tested) usually in /etc/odbc.ini for odbc
To show the effect, here is an example, first with the default, then after changing the locale:
\locale
en_US#collation=binary
select 'me' = 'ME';
?column?
----------
f
(1 row)
SET LOCALE TO 'en_US#colstrength=1';
\locale
en_US#colstrength=1
select 'me' = 'ME';
?column?
----------
t
(1 row)
I am pretty sure there is more to it, but this should get you started.
postgresql-9.0.15 on CentOS 6.5. I have a plperlu function that outputs an INFO message. I want to suppress it during testing (using psql, which also behaves as below), but I can't even seem to do it from a pgAdminIII (1.18.1 for win2003) query window:
SET client_min_messages TO WARNING;
select my_info_outputting_function('lalala')
I run that and look in the "messages" tab, and there's my INFO message.
(This may appear similar to How to suppress INFO messages when running psql scripts , but I don't want to disable INFO messages for my whole session, just part of it and then set the minimum back to NOTICE.)
What am I doing wrong with the above code snippet? Does client_min_messages not apply to pl/perlu functions?
UPDATE: upon further investigation, it seems to happen even with plpgsql functions, not just plperlu functions:
create or replace function my_info_outputting_function() returns void as $$
begin
raise INFO 'this should not appear...';
return;
end;
$$ language plpgsql;
SET client_min_messages TO WARNING;
select my_info_outputting_function();
I run the above snippet in a pgAdminIII query window and "this should not appear" appears in the messages tab. Quoi?
Update 2: I also tried log_min_messages just in case. Same behaviour.
I asked on the postgresql-general mailing list and received an informative answer: what distinguishes INFO from NOTICE is that INFO does not have a level: it's intended to always go through, no matter what client_min_messages or anything else is set to, from functions that you would call specifically for INFO output. So in my case, the appropriate thing is to output only NOTICE from my function.
I am using Sybase ASE 12.5 at the moment. I have a code below:
create procedure test_launcher_fail_wrapper
as
begin
select convert(numeric(2),1234345)
if ##error != 0
begin
select "SP failed to execute"
return 1
end
end
Here, I am trying to convert a very large value/amount (1234345) to Numeric size 2. Which is not possible and it generates error.
Questions:
Is having ##error useful here? I ran this SP and it never went into
error handling
How to error handle these kind of scenarios?
I treat error handling in procs similarly to error handling in applications -- if there's an opportunity for you to contribute some actual value by handling the error, then by all means, do so, but if you can't really do anything to help, then you're better off just letting it go.
As an example of adding value, I've got one or two procs that add contextual information in the error message, like a list of ID values that conflict with an update operation. In this particular case, I know that the upstream consumer of the proc will log this error, and the text will be available to an operator who will find this information valuable when debugging the problem. I also know that while this condition is a real error, it's been known to happen from time-to-time, and the effort to format the error is worthwhile.
Does this catch your error?
create procedure test_launcher_fail_wrapper
as
begin
declare #database_err int
set #database_err = 0
select convert(numeric(2),1234345)
set #database_err = ##error
if #database_err <> 0
begin
PRINT 'SP failed to execute'
return 1
end
end
##error is the way to go but beware since:
Every Transact-SQL statement, including print statements and if tests, resets ##error, so the status check must immediately follow the batch for which success is in question.
As for a suggestion on how to handle error management in similar scenarios, have you considered using raiserror ?
An example:
create procedure proc1 as
begin
select convert(numeric(2),1234345)
if ##error <> 0
begin
raiserror 20001 "Error during convert in proc1"
return 1
end
end