postgresql 11 ERROR: syntax error at or near "`" - postgresql

I installed Mimic3 database in Pg11, and try to query using the code from here: https://mimic.physionet.org/tutorials/intro-to-mimic-iii-bq/ solution to step 1.
SELECT ie.subject_id, ie.hadm_id, ie.icustay_id,
ie.intime, ie.outtime
FROM `physionet-data.mimiciii_clinical.icustays` ie;
but I got the error.
ERROR: syntax error at or near "`"
LINE 3: FROM `physionet-data.mimiciii_clinical.icustays` ie
^
, Time: 0.004000s
And if I deleted those two backticks, I got the warning.
ERROR: syntax error at or near "-"
LINE 3: FROM physionet-data.mimiciii_clinical.icustays ie
^
, Time: 0.002000s
And if I explaced ` with ", it showed the error that:
ERROR: relation "physionet-data.mimiciii_clinical.icustays" does not exist
LINE 3: FROM "physionet-data.mimiciii_clinical.icustays" ie
^
, Time: 0.002000s
Hope somebody can tell me what was wrong. Thank you!

Postgres doesn't use backticks to quote table names, it uses double quotes, and dots aren't allowed in names without quoting, so you probably want this:
SELECT ie.subject_id, ie.hadm_id, ie.icustay_id,
ie.intime, ie.outtime
FROM "physionet-data.mimiciii_clinical.icustays" ie;

Related

Why am I getting an error near semi colon (:)?

I have no idea but this is throwing an error i think it is on line "set #al = 2020". I have read the documentation and not seeming to translate over.
begin
declare #al int;
set #al = 2020;
exec dbo.get_egus_trdg_desk_rpt_no_clrg_broker(#al int);
end
Error message:
SQL Error [102] [42000]: Incorrect syntax near ';'.
You do not need to use ';' after every line of code. I can successfully generate the following script in SQL Server 2019.
Sample Output

what does caret do in postgresql?

I'm playing hackthebox machine's and current one has a postgresql db in place. The query breaks with ' and appeas as follows:
ERROR: unterminated quoted string at or near "'" LINE 1: Select * from
cars where name ilike '%test'%' ^
I understand that % is being used to search within the query string for the characters provided but, What is ^ used for?
Bold highlights my test query
All my searches yielded resulst regarding regexes and caret signaling the start of the string. Plus other result about using cli or something like that.
Can anybody tell me what is it doing at the end of the query?
Your are looking for the use of the caret specifically within error messages.
If I run this query:
psql -c " Select * from cars where name ilike '%test'%'"
This is what I get, preserving line breaks and spaces:
ERROR: unterminated quoted string at or near "'"
LINE 1: Select * from cars where name ilike '%test'%'
^
The caret points to where on the previous line the error occurred. In this case, that is where the opening quote mark that never got closed was located.
If you are using a tool which malformats your error messages, you should consider changing to one that does not or otherwise figuring out how to fix it.

how to convert base64 string to bytea in postgresql8.2

I need to convert base64 string to bytea type. But when I Executed SQL statements by the pgAdminIII:
select decode("ygAAA", 'base64');
I got the following error message:
ERROR: syntax error at or near ")"
LINE 1: select decode('ygAAA', 'base64');
^
********** 错误 **********
ERROR: syntax error at or near ")"
SQL 状态: 42601
字符:59
My postgresql's version is 8.2.15. And I could use encode function.
I googled it, but didn't find the solution. Can somebody help me? TKS!
Try it with single quotes instead of double quotes. Also base 64 strings turn groups of 4 characters into 3 bytes (24 bits in 3 bytes are spread across the lower 6 bits of 4 characters.) So your base64 string is invalid.
This works:
select decode('ygAA', 'base64');
Hope this helps,
Adam.

Is there a way to have Postgres tell you what a syntax error was in addition to what it is at/near?

I've tried setting 'log_min_error_statement' equal to debug5 in postgresql.conf but I'm still getting the standard "PostgreSQL said: syntax error at or near "AS"" error message in both the console and the postgresql log.
If PostgreSQL knew what the error was it'd tell you, at least in most cases.
If it just says "Syntax error at or near ..." it doesn't know what you meant, and can't guess what's wrong. It's a parse error. It could offer a (very long) list of suggestions, but that'd make error messages absurdly verbose, like:
postgres=# SELECT AS fred ORDER BY 1;
ERROR: syntax error at or near "AS"
LINE 1: SELECT AS fred ORDER BY 1;
Yup, that's a syntax error, because it doesn't make sense on any level. What's wrong with it? How do you succinctly describe that? How does a parser even tell what's wrong?
postgres=# SELECT AS fred ORDER BY 1;
ERROR: syntax error at or near "AS"
LINE 1: SELECT AS fred ORDER BY 1;
HINT: typo?
HINT: Did you use a reserved keyword as an identifier without "quoting" it? Like "AS"?
HINT: Did you leave out the value before the AS keyword?
HINT: ... endless possibilities ...
Occasionally a parser can guess something you might've done wrong. PostgreSQL's parser tries to tell you when it can, e.g.
psql -c "SELECT 'openquote";
ERROR: unterminated quoted string at or near "'openquote"
LINE 1: SELECT 'openquote

Does perl DBI support command like this #file_name?

I would like to run commands which is placed in 1.sql file This is my code:
$sth=$dbh->do( q { #1.sql } );
But this code isn't working:
There is output:
DBI::db=HASH(0xf18edc0) trace level set to 0x0/2 (DBI # 0x0/0) in DBI 1.634-ithread (pid 10389)
-> do in DBD::_::db for DBD::Oracle::db (DBI::db=HASH(0xf18ee50)~0xf18edc0 ' #1.sql ') thr#eebf010
dbd_st_execute (STMT TYPE 0) (out0, lob0)...
Statement Execute Mode is 32 (COMMIT_ON_SUCCESS)
-> DESTROY for DBD::Oracle::st (DBI::st=HASH(0xf18f190)~INNER) thr#eebf010
ERROR: 900 'ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ')' (err#1)
<- DESTROY= undef at run.pl line 12
!! ERROR: 900 'ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ')' (err#0)
<- do= undef at run.pl line 12
DBD::Oracle::db do failed: ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ') [for Statement " #1.sql "] at run.pl line 12.
DBD::Oracle::db do failed: ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ') [for Statement " #1.sql "] at run.pl line 12.
! -> DESTROY for DBD::Oracle::db (DBI::db=HASH(0xf18edc0)~INNER) thr#eebf010
ERROR: 900 'ORA-00900: invalid SQL statement (DBD ERROR: error possibly near <*> indicator at char 1 in ' <*>#1.sql ')' (err#0)
! <- DESTROY= undef during global destruction
No, that won't work (obviously). Some DBI drivers support multiple statements (MySQL and SQL Server via ODBC come to mind), but I don't think Oracle does. At any rate, you'd still have to handle the file reading part yourself. As you can see in the DBI docs, do() is expecting a valid SQL statement, which the string #1.sql is not.
Your basic options for executing an SQL file from Perl are:
Split the SQL file yourself and then execute each statement.
If you have control of the file and know it won't contain anything tricky, this is a fairly easy task. It could be as easy as splitting the file based on a semicolon character, or you might want to add some basic stripping of comments first.
However, this is quite hard to do 100% correctly for the full range of possible file content (what if an SQL statement has a string containing a semicolon? What if there are nested sets of comments? etc.). This requires fully parsing the file--and I'm not aware of any tool that allows you to do this easily. There is an SQL::Parse module, but I don't think it handles multiple statements.
Call an external program from Perl to do it for you.
For example, call the Oracle command line client. This is easy, but you don't have granular control of the statements being executed.