HEADER [ boolean ] not allowed in COPY ... FROM statement
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/sql-copy.html Description: > psql --version ; psql (PostgreSQL) 11.2 > initdb --version ; initdb (PostgreSQL) 11.2 The boolean parameter is not allowed in the statement: # COPY table_name FROM '/srv/database/pg_dumps/file.csv' WITH CSV HEADER true DELIMITER ',' QUOTE '"' ; ERROR: syntax error at or near "true" LINE 1: ...pg_dumps/file.csv' WITH CSV HEADER true DELIM... # COPY table_name FROM '/srv/database/pg_dumps/file.csv' WITH CSV HEADER 'true' DELIMITER ',' QUOTE '"' ; ERROR: syntax error at or near "'true'" LINE 1: ...pg_dumps/file.csv' WITH CSV HEADER 'true' DEL... ^ # COPY table_name FROM '/srv/database/pg_dumps/file.csv' WITH CSV HEADER 1 DELIMITER ',' QUOTE '"' ; ERROR: syntax error at or near "1" LINE 1: ...pg_dumps/file.csv' WITH CSV HEADER 1 DELIMITE... # COPY table_name FROM '/srv/database/pg_dumps/file.csv' WITH CSV HEADER DELIMITER ',' QUOTE '"' ; COPY 63
FORMAT keyword not allowed in COPY ... FROM statement
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/11/sql-copy.html
Description:
> psql --version ;
psql (PostgreSQL) 11.2
> initdb --version ;
initdb (PostgreSQL) 11.2
# \h copy
Command: COPY
Description: copy data between a file and a table
Syntax:
COPY table_name [ ( column_name [, ...] ) ]
FROM { 'filename' | PROGRAM 'command' | STDIN }
[ [ WITH ] ( option [, ...] ) ]
COPY { table_name [ ( column_name [, ...] ) ] | ( query ) }
TO { 'filename' | PROGRAM 'command' | STDOUT }
[ [ WITH ] ( option [, ...] ) ]
where option can be one of:
FORMAT format_name
OIDS [ boolean ]
FREEZE [ boolean ]
DELIMITER 'delimiter_character'
NULL 'null_string'
HEADER [ boolean ]
QUOTE 'quote_character'
ESCAPE 'escape_character'
FORCE_QUOTE { ( column_name [, ...] ) | * }
FORCE_NOT_NULL ( column_name [, ...] )
FORCE_NULL ( column_name [, ...] )
ENCODING 'encoding_name'
# COPY table_name FROM '/srv/database/pg_dumps/file.csv' WITH FORMAT CSV
HEADER DELIMITER ',' QUOTE '"' ;
ERROR: syntax error at or near "FORMAT"
# COPY table_name FROM '/srv/database/pg_dumps/file.csv' WITH CSV HEADER
DELIMITER ',' QUOTE '"' ;
COPY 63
Re: Improve documentation for current_setting function
Hello Bruce, > How do you like the attached patch, which clarifies this? >>in which case a missing parameter returns >>! NULL. not always. It can be NULL or empty string. It depends if the current session is new or after finished transaction which makes 'local' changes to setting Take into account these steps: https://www.postgresql.org/message-id/15646-0d3caee9f6266f60%40postgresql.org From my user point of view. if the boot value before transaction was NULL then after transaction it MUST stay NULL and not empty string. This will be consistent with that if I open new parallel session it will return NULL. Also I see NULL value (if setting was not defined) is useful. Also this: set_config( 'my.name', NULL ) must set 'my.name' to NULL or must issue warning about NULL is turned into empty string. Personally I dislike that NULL is converted to empty string. This looks ugly. =( -- Best regards, Eugen Konkov
Postgres make uninstall
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/install-procedure.html Description: If we configure build with a different prefix than the default, "make uninstall" doesn't work. Example if i run configure as below. 1) ./configure --prefix=/home/user/pgsql and then build and install the postgres. And try to uninstall by using 2) make uninstall -- >This command still tries to uninstall from the default prefix of /usr/local/pgsql/ Can make uninstall be changed to uninstall from the prefix location given in configure command?
Re: Improve documentation for current_setting function
On Fri, Feb 22, 2019 at 11:43:54AM +0200, Eugen Konkov wrote: > Hello Bruce, > > > How do you like the attached patch, which clarifies this? > > >>in which case a missing parameter returns > >>! NULL. > > not always. It can be NULL or empty string. It depends if the current > session is new or after finished transaction which makes 'local' changes > to setting > > Take into account these steps: > https://www.postgresql.org/message-id/15646-0d3caee9f6266f60%40postgresql.org Yes, I saw that recent thread. > From my user point of view. if the boot value before transaction was > NULL then after transaction it MUST stay NULL and not empty string. > > This will be consistent with that if I open new parallel session it > will return NULL. > > Also I see NULL value (if setting was not defined) is useful. > > > Also this: > set_config( 'my.name', NULL ) > must set 'my.name' to NULL or must issue warning about NULL is turned > into empty string. > > Personally I dislike that NULL is converted to empty string. This > looks ugly. =( Understood. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
