We are working on merging individual files into a group PostgreSQL database. The files have all been working perfectly fine on their own and when we have combined we have run them with no problems. It started to hang on the creation of one trigger, so we commented the trigger out. The next time we ran the merge file we got the following error:
ERROR: Syntax error at end of input
LINE 181: --$$ LANGUAGE plpgsql
Following this error there were subsequent syntax errors and then to our horror we found the following in our log file:
ERROR: Syntax error at end of input
LINE 181: --$$ LANGUAGE plpgsql
COMMIT
We had tests in this file that contained test data that was NOT supposed to be entered into the database, corrupting who knows how much of the data in our database. We have looked through every file included and there is no COMMIT anywhere!
Has anyone ever run into something similar? Is there any reason why an error in parsing would ever cause a commit?
If you don't have a BEGIN statement, then the PostgreSQL connection is in "autocommit" mode, committing each change after the statement is run. Since you're incorrectly commenting your code, I'd say you've commented the BEGIN statement earlier in the code. But I can't be sure because you did not provide any of your SQL.
Note that the syntax:
--$$
does not comment out the end of function $$. What it means is empty comment as the last thing inside a string. It might help you if you read the line as:
--
$$
That is why you're getting a parse error on a "commented" line. If it was actually commented, PostgreSQL would not parse it. $$ is a quote operator enclosing SQL code, and is just a convenience syntax against using ''s for quoting (which would mean you have to double-quote each quote inside the quoted SQL). What you think was a commented out line was actually just a piece of a string ending with two hyphens.
On a general note: You should use commenting only for adding descriptions to the code and not disabling sections of code. Use version control if you need to have access to older versions of the code.
Edit: Clarified explanation on quoted strings. Hope this makes more sense now.
Related
When I make a query in Aginity with an error in it, it gives a notification like
ERROR: '[My SQL here]'
error
^ found "INSERT" (at char 2292) expecting `SELECT' or `'(''
If I click on the location of that error in my SQL, it's actually at Position: 3934. I think Aginity is disregarding the whitespace when it tries to say where the error is. Is there a way to make it show the position in the builder?
It's not Aginity that does this, it's somewhere up the software stack (I suspect it's on the actual Netezza itself).
What I do (and this is a POOR solution) is to remove the whitespace myself.
Since I use Unix (mostly) and Vim this is a little easier than in Aginity.
It really is a PITA, and IBM should proved a better solution (one would be to kick back the SQL statement as run with all the whitespace removed).
I have the following select statement:
select * from '/MOUNT_NAME/DB_NAME/TABLE_NAME'
Where MOUNT_NAME, DB_NAME, TABLE_NAME are just what they say they are.
The above syntax works just fine in the generated SQL statement when first opening a notebook and exploring the data. However, when I type in the same thing in a SQL window created in that notebook I get the following error:
operator '(' expected; '/MOUNT_NAME/DB_NAME/TABLE_NAME'
Any suggestions? Am I misusing the Notebook behavior for writing just simple syntax? Must be doing something wrong since this seems so straightforward. Any clarification out there?
The correct query would be:
SELECT * FROM `/MOUNT_NAME/DB_NAME/TABLE_NAME`
Note the use of back-ticks (not single quotes) to escape identifiers, which changed recently when SlamData was updated to use the latest version of Quasar. It looks like not all documentation on the SlamData website has been updated yet.
For ex, I have a query in postgreSQL such that "product_version=:productVersion".
It's giving me a syntax error.
It's giving you a syntax error because it makes no sense as SQL, and is invalid syntax.
(Please always show the exact text of error messages*)
Since inserting the string literal :productVersion doesn't make much sense, e.g.
product_version=':productVersion'
you might be using the psql command line client and trying to substitute a client variable. If so, you need to use a quoted substitution, e.g.:
product_version=:'productVersion'
but this only works for psql. Not Rails and the Pg gem, not JDBC, not PHP, not psycopg2, nothing but psql.
If that's not what you meant, then either you are using a programming language with placement parameters and using the wrong parameter syntax for your language, or you are attempting to use the psql command line client's variable substitution and aren't using psql. Impossible to guess what you mean unless you specify the language/tools used.
Look up the placement parameter syntax for your programming language and database driver. Make sure you're using the right one.
I know this will be a forehead slapper. When I highlight and execute my copy command it works fine. However, when I put it in a do statement and execute, I get the error:
ERROR: syntax error at or near "Warner"
I looked around and couldn't find an obvious solution. I moved the semi-colon at the end of the do statement, removed it, the error will not go away. Any ideas anyone? Thanks...
DO
$$
BEGIN
COPY _tmp_employer_create FROM STDIN;
Warner Bros. Entertainment Inc. Manually Entered Manually_Entered-Unverified STUDIO
Disney. Entertainment. Manually Entered Manually_Entered-Unverified STUDIO
\.
END;
$$
Why you use a inline block (DO statement) here? It has no sense. More - inline block is parsed to syntax tree - it means so it is effective disconnected from stdin - so there is no way, how to use a COPY together with data inside DO statement.
Any access from server side scripts to stdin or stdout is terrible difficult - and on typical level is impossible.
I am retrieving the following sql statement from a table and then using bind variables to substitute the values in. I get a syntax error when running the statement. It seems to be occurring as a result of the lower() function however I believe I am using this correctly. I have tried running the statement manually via psql and it works fine with the values I provide. Does anyone have any ideas on this one? I have tried switching the ' for $$ but this had no effect.
statement
SELECT column_name
FROM information_schema.columns
WHERE table_name=lower(':1')
and column_name=lower(':2')
expected basic statement with substituted values
SELECT column_name
FROM information_schema.columns
WHERE table_name=lower('MyTableName')
and column_name=lower('MyColumnName')
statement run by postgresql
SELECT column_name
FROM information_schema.columns
WHERE table_name=lower('((E'RWOL_TMA_ROADWORKS'))')
and column_name=lower('((E'TPHS_CWAY_RESTRICT_TYPE'))')
Error in C#
ERROR: 42601: syntax error at or near \"MyTableName\"
Error in PostgreSQL log file
2012-04-16 11:36:15 BST ERROR: syntax error at or near "RWOL_TMA_ROADWORKS" at character 80
2012-04-16 11:36:15 BST STATEMENT: SELECT column_name FROM information_schema.columns WHERE table_name=lower('((E'RWOL_TMA_ROADWORKS'))') and column_name=lower('((E'TPHS_CWAY_RESTRICT_TYPE'))')
EDIT: Retrieval and implementation code is written in C#. I use the database connection base classes and the npgsql provider factory in order to make connections, run queries and retrieve the data. This method works for all other queries that use this method of binding variables etc apart from this one where I try to use the lower() function.
EDIT: I have tried removing the quotes altogether to let the binding agent deal with quoting the values and this provided the same syntax error.
EDIT: Have now enabled logging and added the actual statement that postgresql is running.
I think vyegorov is on the right path - there's something funny with your placeholders.
I don't think your second example is the actual query after substition because that doesn't contain any errors. Where did it come from and why aren't you providing the actual query - do you have statement logging turned on in PostgreSQL?
Also, I'm suspicious of the syntax error - what's going on with the escaped double-quotes? Are they actually double-quotes and not doubled-up single quotes?
Are you sure you need single-quotes around your placeholders? Usually the drivers manage that for you.
Are you sure you aren't double-quoting the values anywhere?
Get the actual SQL and look at the quoting and the problem will be obvious I suspect.
UPDATE: now have SQL
Here's the error in the posted statement:
lower('((E'RWOL_TMA_ROADWORKS'))')
You've got two levels of quotes here. Remove the ones you've added and we should end up with something like:
lower((E'RWOL_TMA_ROADWORKS'))
Ignoring the repeated brackets that's valid (The E'...' is the syntax for a c-style escaped string - google around standard_conforming_strings).
Maybe you shouldn't use quotes around :1 and :2. Most APIs that support bind variables will correctly quote the value for you.
I think that it is not lower() functions' issue, but rather bind variable processing issue.
As #Adrian suggests, try not to use quotes around your bind variables.
And you should also consult your databases logs, you'll see more information there about what's going on.
EDIT: Use:
SHOW data_directory;
SHOW log_directory;
SQL statement to find the locations of your DATA directory and logs location, if logs path is relative, then it will be relative to the DATA directory.
Go there and find the recently modified file, check the contents. You should see the error message with default PostgreSQL configuration.
And it'd be good for you to enable debugging also on the middleware / factory levels.