Is there an equivalent in PostgreSQL of the Oracle SQLPLUS "set echo on" so that I can get batch input
statements echoed in the output?
I have a very large file with input statements in it that has a few errors when I run it.
I am having difficulty finding the statement that produced the error because psql is only reporting
the error - not the statement that generated the error.
You need to pass the -a (or --echo-all) argument to psql. It's described at https://www.postgresql.org/docs/current/static/app-psql.html under OPTIONS.
PostgreSQL also logs errors in its server logs, along with the statement that caused it. That might be useful to bear in mind for debugging errors with tools other than psql that don't report errors very well.
Related
I'm trying to import a SQL backup file but I keep getting the error
todolist-# psql todolist < C:\Users\ojadi\Documents\todolist2.sql
invalid command \Users
Try \? for help.
todolist-#
That is a command you give in UNIX shell, not a command you give in psql. Since it seems you already have psql running, you can run the file using command
\i C:\Users\ojadi\Documents\todolist2.sql
Note that your prompt todolist-# indicates you are in the middle of writing a command in psql. See my answer to this earlier question
I have a very big SQL dump I'm working on. The overall structure looks like this:
BEGIN;
SET CONSTRAINTS ALL DEFERRED;
INSERT …;
-- … ~300K insert operations
INSERT …;
COMMIT;
The problem is if there is an error in any single statement, then error is shown and the message current transaction is aborted, commands ignored until end of transaction block is generated for EACH statement that follows it.
Why does it behave so weirdly? Is there a way to suppress the following messages? It's enough to just show the real error message and to skip transaction execution. I don't want to see ~300K meaningful error messages.
Do I need to structure my dump differently? Or is there a flag/option I can use?
Presumably you're using psql to send the queries to the server.
You may set the ON_ERROR_STOP built-in variable to on.
From https://www.postgresql.org/docs/current/static/app-psql.html:
ON_ERROR_STOP
By default, command processing continues after an error. When this
variable is set to on, processing will instead stop
immediately. In interactive mode, psql will return to the command
prompt; otherwise, psql will exit, returning error code 3 to
distinguish this case from fatal error conditions, which are
reported using error code 1.
It may be set from outside psql with psql -v ON_ERROR_STOP=on -f script.sql, or from inside the script or interactively with the meta-command \set ON_ERROR_STOP on.
pg_dump does not have an option to add this automatically to a dump (as far as I know, it doesn't emit any psql meta-command anyway, only pure SQL commands).
http://pgtap.org/integration.html#perl mentions how to run the tests, but I cannot find an example of a Perl test case.
Do I have to get a DBI connection manually, run my commands on it, and check the results?
Does it even make sense to use Perl vs SQL code?
Am I missing something?
pgTap is for parsing SQL output - output from running an SQL script via psql from the command line. An SQL script that contains pgTap SQL calls mixed in with the SQL statements that you wish to test.
As such, DBI doesn't enter into it.
I am writing a KSH script to accept a .sql file parameter followed by each schema that file is to be compiled in. The script assumes the .sql file is a DB2 9.7 procedure.
I believe I am stuck on the syntax of the db2 command for the termination character. We always use the at symbol ('#'), however the following snippet fails with error "DB21001E The option "-#" specified after the 'db2' command or in the DB2OPTIONS variable is incorrect." Any assistance would be greatly appreciated.
#!/bin/ksh
. $IBM_DB_DIR/db2profile
db2 connect to dwdev3
const_compil_string_suffix="-vtd# -f ../../stored_procedures/"
script_name="ETL.THING.sql"
db2 "$const_compil_string_suffix$script_name"
db2 terminate
I have confirmed that the resulting string command above the 'terminate' does work at linux prompt compiling the procedure as expected:
db2 -vtd# -f ../../stored_procedures/ETL.THING.sql
Thank you in advance.
Try losing the quotation marks:
db2 ${const_compil_string_suffix}${script_name}
I suspect the option string -vtd# might be the culprit.
When using single character options most unix command accept two types of options, those with and those without arguments.
Apparently the # character is being processed as an option argument, however the error message indicates it is seen as an option on its own.
Try separating the options, as in: -v -t -d#, reorder them. or remove one of the -t or -v options.
Beware though. I have no knowledge about the db2 cli. Experiment at your own risk.
Was the -t option added later?
Is there a way to specify that when executing a sql script it stops when encountering the first error on the script, it usually continues, regardless of previous errors.
I think the solution to add following to .psqlrc is far from perfection
\set ON_ERROR_STOP on
there exists much more simple and convenient way - use psql with parameter:
psql -v ON_ERROR_STOP=1
better to use also -X parameter turning off .psqlrc file usage.
Works perfectly for me
p.s. the solution found in great post from Peter Eisentraut. Thank you, Peter!
http://petereisentraut.blogspot.com/2010/03/running-sql-scripts-with-psql.html
I assume you are using psql, this might be handy to add to your ~/.psqlrc file.
\set ON_ERROR_STOP on
This will make it abort on the first error. If you don't have it, even with a transaction it will keep executing your script but fail on everything until the end of your script.
And you probably want to use a transaction as Paul said. Which also can be done with psql --single-transaction ... if you don't want to alter the script.
So a complete example, with ON_ERROR_STOP in your .psqlrc:
psql --single-transaction --file /your/script.sql
It's not exactly what you want, but if you start your script with begin transaction; and end with end transaction;, it will actually skip everything after the first error, and then it will rollback everything it did before the error.
I always like to reference the manual directly.
From the PostgreSQL Manual:
Exit Status
psql returns 0 to the shell if it finished normally, 1 if a fatal
error of its own occurs (e.g. out of memory, file not found), 2 if the
connection to the server went bad and the session was not interactive,
and 3 if an error occurred in a script and the variable
ON_ERROR_STOP was set.
By default if the sql code you are running on the PostgreSQL server error psql won't quit an error. It will catch the error and continue. If, as mentioned above, you set the ON_ERROR_STOP setting to on, when psql catches an error in the sql code it will exit and return 3 to the shell.