On 11/08/2011 7:56 PM, Siva Palanisamy wrote:
> FYI, I am using PostgreSQL 8.1.4.
Argh, ogod why?!?!?!
That version is *totally* unsupported on Windows. Not only that, but
you're running an ancient point-release - you are missing *19* patch
releases worth of bug fixes. The latest point-releas
>
> COMMAND: copy (select * from employee) to 'C:/emp.csv'
> ERROR: could not open file "C:/emp.csv" for writing: Permission denied
> ** Error **
> ERROR: could not open file "C:/emp.csv" for writing: Permission denied
> SQL state: 42501
>
> COMMAND: \copy (select * from employee)
ounts of both Windows Login and PostgreSQL.
Thanks and Regards,
Siva.
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Boszormenyi Zoltan
Sent: Thursday, August 11, 2011 5:11 PM
To: pgsql-general@postgresql.org
Subject: Re: [GEN
--
> From: pgsql-general-ow...@postgresql.org
> [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Siva Palanisamy
> Sent: Thursday, August 11, 2011 4:48 PM
> To: Andreas Kretschmer; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Copy command to handle view for my export r
Regards,
> Siva.
>
>
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:
> pgsql-general-ow...@postgresql.org] On Behalf Of Siva Palanisamy
> Sent: Thursday, August 11, 2011 4:48 PM
> To: Andreas Kretschmer; pgsql-general@postgresql.org
> Subject: Re: [G
@postgresql.org
Subject: Re: [GENERAL] Copy command to handle view for my export requirement
Hi Andreas,
I tried the command as below. It failed. Please correct me.
\copy (select * from view1) to '/sample.csv' delimiters ',' csv header;
ERROR: \copy: parse error at "se
@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Andreas Kretschmer
Sent: Thursday, August 11, 2011 2:23 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Copy command to handle view for my export requirement
Siva Palanisamy wrote:
> Hi All,
>
>
>
>
Siva Palanisamy wrote:
> Hi All,
>
>
>
> I understand that copy and \copy commands in PostgreSQL work only for tables.
> I
> want it to export the data from varies tables. Instead, I can create a view
> for
> the list of tables. Can the copy or \copy commands be utilized to operate on
> vie
On Wed, Jul 20, 2011 at 8:53 PM, Vibhor Kumar
wrote:
> You can use STDOUT to pipe output to a shell command and STDIN to read input
> from shell command.
> Something like given below:
> psql -c "COPY mytable to STDOUT"|gzip >/home/tgl/mytable.dump.gz
>
> cat filename|psql -c "COPY mytable from ST
On 21/07/11 01:59, david.sahag...@emc.com wrote:
> From May 31, 2006; 12:03pm . . .
>
> "It struck me that we are missing a feature that's fairly common in Unix
> programs.
> Perhaps COPY ought to have the ability to pipe its output to a shell command,
> or read input from a shell command. "
> Ma
On Jul 20, 2011, at 11:29 PM,
wrote:
> From May 31, 2006; 12:03pm . . .
>
> "It struck me that we are missing a feature that's fairly common in Unix
> programs.
> Perhaps COPY ought to have the ability to pipe its output to a shell command,
> or read input from a shell command. "
> Maybe som
Hi Oisin,
I am right in the condition you described, but nowadays the 8.0
documentation is only available without comments.
I tried the way suggested by Richard Sydney-Smith (*eliminating the spaces
in the path*), but unsuccessfully.
Could you please help me?
thanks, Fabio
*hint from Richard Sydne
On Thu, May 26, 2011 at 3:23 PM, Gauthier, Dave wrote:
> Hi:
>
>
>
> From within a perl/DBI script, I want to be able to make a copy of a record
> in a table, changing only the value of the primary key. I don't know in
> advance what all the columns are, just the table name.
>
>
>
> I suppose I c
On 2011-05-26, Bosco Rama wrote:
> select * into temp table foo from maintable where primcol=123;
> update foo set primcol = 456;
> insert into maintable select * from foo;
>
> You also may need this is if you intend to use the same sequence of
> calls on within the same session:
>
> drop
Gauthier, Dave wrote:
> Well, I found a better way, but still open to suggestions.
>
> This is what I have so far...
>
> create temporary table foo as select * from maintable where 1-0; -- Credit 4
> this goes to a post in the PG archives
> insert into foo (select * from maintable where primcol
Well, I found a better way, but still open to suggestions.
This is what I have so far...
create temporary table foo as select * from maintable where 1-0; -- Credit 4
this goes to a post in the PG archives
insert into foo (select * from maintable where primcol=123);
update foo, set primcol=456;
On Tue, 10 May 2011 15:59:07 +0200
Ivan Sergio Borgonovo wrote:
Sorry for the noise. The csv was automatically generated. The code
was right but during generation there was some problem with the box
generating it (php segfaulting) and there were some unclosed quotes
in a much earlier line.
Postg
On Tue, 10 May 2011 14:38:23 +0200
Pavel Stehule wrote:
> Hello
>
> COPY doesn't like '\n' too.
>
> Replace '\n' by '\\n'
mmm maybe you were mislead by the "semi-transliterated" hexdump.
There is no "slash" in the record, the actual input was the one
reported in hex. The following line was ju
Hello
COPY doesn't like '\n' too.
Replace '\n' by '\\n'
Regards
Pavel Stehule
2011/5/10 Ivan Sergio Borgonovo :
> I'm on pg 8.3.14
> I'm trying to import a csv with
>
> \copy anagraficaclienti from
> 'myfile.csv'
> delimiter as E' ' -- this is a tab \t
> null as 'NULL'
> csv
> he
On 10/02/2011 17:13, Samuel Gilbert wrote:
Hello all,
I'm using a COPY statement to load data into a PostGIS. The issue I am
facing is that if I define fields with the REAL type, the COPY will only
preserve 4 decimals which is not sufficient for my application.
If you use NUMERIC, you can
Le 23/12/2010 14:36, Mark Watson a écrit :
> Le 22/12/2010 21:34, Mark Watson a écrit :
>> Hello all,
>> (Postgres 8.4.6 Windows)
>> I am stumped as to why I cannot import this using copy from within
pgadmin
>> (the following table is created in an existing database with an encoding
> of
>> WIN1252
Le 23/12/2010 14:36, Mark Watson a écrit :
> Le 22/12/2010 21:34, Mark Watson a écrit :
>> Hello all,
>> (Postgres 8.4.6 Windows)
>> I am stumped as to why I cannot import this using copy from within pgadmin
>> (the following table is created in an existing database with an encoding
> of
>> WIN1252
Le 22/12/2010 21:34, Mark Watson a écrit :
> Hello all,
> (Postgres 8.4.6 Windows)
> I am stumped as to why I cannot import this using copy from within pgadmin
> (the following table is created in an existing database with an encoding
of
> WIN1252 and the Postgres server_encoding is UTF8) :
> CREAT
Le 22/12/2010 21:34, Mark Watson a écrit :
> Hello all,
> (Postgres 8.4.6 Windows)
> I am stumped as to why I cannot import this using copy from within pgadmin
> (the following table is created in an existing database with an encoding of
> WIN1252 and the Postgres server_encoding is UTF8) :
> CREAT
On Wednesday 22 December 2010 12:34:58 pm Mark Watson wrote:
> Hello all,
> (Postgres 8.4.6 Windows)
> I am stumped as to why I cannot import this using copy from within pgadmin
> (the following table is created in an existing database with an encoding of
> WIN1252 and the Postgres server_encoding
On Monday 20 December 2010 7:09:23 am Leif Biberg Kristensen wrote:
> On Monday 20. December 2010 15.24.58 Jorge Godoy wrote:
> > With OpenOffice.org that 65K limit goes away as well...
> >
> > I don't know why it is still like that today for MS Office... It is
>
> almost
>
> > 2011 and they still
On Monday 20. December 2010 15.24.58 Jorge Godoy wrote:
> With OpenOffice.org that 65K limit goes away as well...
>
> I don't know why it is still like that today for MS Office... It is
almost
> 2011 and they still think 64K is enough? :-)
Maybe there's an uncrippled «Professional» or «Enterpri
lp in this case.
>
> -Mark
> --
>
> *De :* pgsql-general-ow...@postgresql.org [mailto:
> pgsql-general-ow...@postgresql.org] *De la part de* Adrian Klaver
> *Envoyé :* 18 décembre 2010 18:05
> *À :* pgsql-general@postgresql.org
> *Cc :* Mark Watson
> *Objet :*
his case.
-Mark
_
De : pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] De la part de Adrian Klaver
Envoyé : 18 décembre 2010 18:05
À : pgsql-general@postgresql.org
Cc : Mark Watson
Objet : Re: [GENERAL] Copy From suggestion
On Friday 17 December 2010 7:46
On Friday 17 December 2010 7:46:12 am Mark Watson wrote:
> Hello all,
> Firstly, I apologise if this is not the correct list for this subject.
> Lately, I've been working on a data conversion, importing into Postgres
> using Copy From. The text file I'm copying from is produced from an ancient
> pr
Le lundi 06 décembre 2010 à 18:27 -0600, Sairam Krishnamurthy a écrit :
You should start a new thread for this
> Is there a way to call a rule when I use "COPY FROM" instead of
> "INSERT INTO"
>
from the doc :
COPY FROM will invoke any triggers and check constraints on the
destination table.
>From the 8.3 docs...
"Be aware that COPY ignores rules. ... COPY does fire triggers, so you can
use it normally if you use the trigger approach."
HTH,
Brent Wood
All,
I have a rule written on a temp table which will copy the valuesinserted into
it to another table applying a fu
On 10/22/2010 05:16 AM, Szymon Guz wrote:
Hi,
I still get the same error while using COPY FROM 'file'. I have to pass
the full directory for this to work, example:
Sounds like you want to be using psql's \copy, not the server side COPY.
\copy is aware of your current working directory and does
On 21/10/2010 22:16, Szymon Guz wrote:
Hi,
I still get the same error while using COPY FROM 'file'. I have to pass
the full directory for this to work, example:
COPY first (a,b,c) FROM '1st_file.csv' with csv header delimiter ',';
ERROR: could not open file "1st_file.csv" for reading: No such f
On 21 October 2010 23:28, Raymond O'Donnell wrote:
> On 21/10/2010 22:16, Szymon Guz wrote:
>
>> Hi,
>> I still get the same error while using COPY FROM 'file'. I have to pass
>> the full directory for this to work, example:
>>
>> COPY first (a,b,c) FROM '1st_file.csv' with csv header delimiter '
On 9/09/2010 2:48 AM, Donald Catanzaro, PhD wrote:
So, latitude is a double precision column and I think that PostgreSQL is
interpreting the double quote as a NULL string
No, it's interpreting it as an empty string, not NULL. I suspect that's
what you meant, but "NULL string" is still NULL, yo
Hi All,
I am apparently totally misreading how to import data using the COPY
FROM command, can someone give assistance ?
I have two issues, both dealing with double quotes as NULL. The data is
CSV with NULL being represented by a double quote (e.g. "") in all
columns of the table.
ISSUE
On 08/07/10 17:42, Alban Hertroys wrote:
> On 8 Jul 2010, at 4:21, Craig Ringer wrote:
>
>> Yes, that's ancient. It is handled quite happily by \copy in csv mode,
>> except that when csv mode is active, \xnn escapes do not seem to be
>> processed. So I can have *either* \xnn escape processing *or*
On 8 Jul 2010, at 4:21, Craig Ringer wrote:
> Yes, that's ancient. It is handled quite happily by \copy in csv mode,
> except that when csv mode is active, \xnn escapes do not seem to be
> processed. So I can have *either* \xnn escape processing *or* csv-style
> input processing.
>
> Anyone know
On Wed, Jul 7, 2010 at 9:21 PM, Craig Ringer
wrote:
> Hi folks
>
> I have an odd csv input format to deal with. I'm about to put some
> Python together to reprocess it, but I thought I'd check in and see if
> I'm missing something obvious in \copy's capabilities.
>
> The input is fairly convention
> > This adds significant complexity to your code, especially since (AFAIK)
> > there aren't really any good i18n tools for Pg's SQL, PL/PgSQL, etc.
>
> But there is - whether good or not: Go to
> http://gitorious.org/gnumed and browse the tree under
> gnumed/server/SQL/. Look at the i18n schema
Merlin Moncure writes:
> On Wed, Jun 23, 2010 at 3:21 PM, Jamie Kahgee wrote:
>> I have an application in a schema and now i need to create other schemas b/c
>> the app needs to support different languages, is there an easy way to copy
>> an entire schema to a new one (tables, contents, trigges,
On Thu, Jun 24, 2010 at 11:29:48AM +0800, Craig Ringer wrote:
> You might want to investigate internationalization options instead,
> where you can process your "master" sources to produce a list of
> strings, and have translators translate those strings. Your code loads
> the string lists, and de
On 24/06/10 03:21, Jamie Kahgee wrote:
> I have an application in a schema and now i need to create other schemas
> b/c the app needs to support different languages, is there an easy way
> to copy an entire schema to a new one (tables, contents, trigges,
> functions, etc..)?
Others have replied w
On Wed, Jun 23, 2010 at 3:21 PM, Jamie Kahgee wrote:
> I have an application in a schema and now i need to create other schemas b/c
> the app needs to support different languages, is there an easy way to copy
> an entire schema to a new one (tables, contents, trigges, functions, etc..)?
> right n
On 2010-05-21, Kevin Kempter wrote:
> Can I copy from one db (via COPY) and pipe the results to a psql/COPY stmt so
> I can load the data into a table in the second db 'inline' without writing to
> & reading from a flat file?
Yes.
COPY ... TO stdout;
at the source and
COPY ... FROM stdi
On Thu, May 20, 2010 at 10:59 PM, Kevin Kempter
wrote:
> Can I copy from one db (via COPY) and pipe the results to a psql/COPY stmt so
> I can load the data into a table in the second db 'inline' without writing to
> & reading from a flat file?
That's pretty much what
pg_dump -t tablename -d dbn
In response to Kevin Kempter :
> Can I copy from one db (via COPY) and pipe the results to a psql/COPY stmt so
> I can load the data into a table in the second db 'inline' without writing to
> & reading from a flat file?
Yes, but keep in mind, COPY cant create the table on the destination. If
th
paulo matadr wrote:
> When I try to import big file base.txt( 700MB),I get this:
>
> x=# create table arquivo_serasa_marco( varchar(3000));
> x=# COPY arquivo_serasa_marco from
> '/usr/local/pgsql/data/base.txt';
> ERROR: literal newline found in data
> HINT: Use "\n" to represent newli
On 03/09/2010 10:09 AM, Thomas Kellerer wrote:
Raymond O'Donnell wrote on 09.03.2010 18:39:
This is Postgres you're talking about - of course it's that easy! :-)
:)
The main reason I asked, was that the manual actually claims that '\t'
can be used ("The following special backslash sequences a
Thomas Kellerer writes:
> The main reason I asked, was that the manual actually claims that '\t' can be
> used ("The following special backslash sequences are recognized by COPY FROM")
\t is recognized in the copy data, not in the command's parameters.
regards, tom lane
Raymond O'Donnell wrote on 09.03.2010 18:39:
This is Postgres you're talking about - of course it's that easy! :-)
:)
The main reason I asked, was that the manual actually claims that '\t' can be used
("The following special backslash sequences are recognized by COPY FROM")
As this is part o
On 09/03/2010 17:30, Thomas Kellerer wrote:
> Tom Lane wrote on 09.03.2010 18:21:
>> Thomas Kellerer writes:
>>> \copy foo (foo, bar) from foobar.txt delimiter as '\t' csv header
>>
>>> So how can I specify a tab character if I also need to specify that
>>> my file has a header line?
>>
>> Type an
Tom Lane wrote on 09.03.2010 18:21:
Thomas Kellerer writes:
\copy foo (foo, bar) from foobar.txt delimiter as '\t' csv header
So how can I specify a tab character if I also need to specify that my file has
a header line?
Type an actual tab.
Blush
That easy?
Thanks
Thomas
--
Se
Thomas Kellerer writes:
> \copy foo (foo, bar) from foobar.txt delimiter as '\t' csv header
> So how can I specify a tab character if I also need to specify that my file
> has a header line?
Type an actual tab.
regards, tom lane
--
Sent via pgsql-general mailing list
Peter Headland wrote:
> In respect of Bruce's proposed changes, I prefer the original wording
> (for the same reasons as Tom), but with the addition of the mention of
> the server - "... read from or written to a file directly by the
> server".
OK, done with the attached patch.
--
Bruce Momjia
, 2010 22:01
To: Tom Lane
Cc: Peter Headland; Adrian Klaver; pgsql-general@postgresql.org
Subject: Re: [GENERAL] COPY command character set
Tom Lane wrote:
> Bruce Momjian writes:
> > I have updated the documentation to be more direct about COPY
encoding
> > behavior. Patch attached
Tom Lane wrote:
> Bruce Momjian writes:
> > I have updated the documentation to be more direct about COPY encoding
> > behavior. Patch attached and applied.
>
> Uh, why exactly do you find that better? "Processes data" seems a lot
> vaguer to me than the previous wording. I certainly don't thi
Bruce Momjian writes:
> I have updated the documentation to be more direct about COPY encoding
> behavior. Patch attached and applied.
Uh, why exactly do you find that better? "Processes data" seems a lot
vaguer to me than the previous wording. I certainly don't think that
this does much to ad
ber 10, 2009 11:06
> To: Peter Headland
> Cc: pgsql-general@postgresql.org; Tom Lane
> Subject: Re: [GENERAL] COPY command character set
>
>
> - "Peter Headland" wrote:
>
> > > The COPY command reference page saith
> > >
> > >I
Scott Bailey writes:
> PgFoundry has http://pgfoundry.org/projects/pgloader/
> It is a step in the right direction but definitely not as powerful as
> sql*loader.
Yeah, it's only offering what I needed and what I've been requested to
add. So far there's support for INFORMIX UNLOAD files, mysqldum
Marc Mamin wrote:
Hello,
Looking at the TODO List, I feel that only some aspects of the COPY FROM
command are adressed.
Could a discussion trigger some activity on this topic :o) ?
Best regards,
Marc Mamin
Here my wish list:
COPY tablename [ ( column [, ...] ) ]
FROM { 'filename' |
Marc Mamin wrote:
Looking at the TODO List, I feel that only some aspects of the COPY
FROM command are adressed.
Could a discussion trigger some activity on this topic :o) ?
(Sounds only of crickets chirping)...guess not. I would love to have
FEEDBACK added.
The TODO list doesn't have
On 14/10/2009 15:28, Chase, John wrote:
> That makes sense, of course. I'm guessing this is because I formally
> used the pgInstaller and since 8.4 is not supported yet by pgInstaller I
> moved to the EnterpriseDB installer. The man behind the current must
As I understand it, pgInstaller is going
nesday, October 14, 2009 10:29 AM
To: pgsql-general@postgresql.org
Subject: RE: [GENERAL] COPY BINARY 8.3 to 8.4 timestamp incorrect
That makes sense, of course. I'm guessing this is because I formally
used the pgInstaller and since 8.4 is not supported yet by pgInstaller I
moved to the Enterpr
"Chase, John" writes:
> That makes sense, of course. I'm guessing this is because I formally
> used the pgInstaller and since 8.4 is not supported yet by pgInstaller I
> moved to the EnterpriseDB installer. The man behind the current must
> have done the build with different options. Would you con
k the man behind the curtain (Dave Page).
Thanks!
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Wednesday, October 14, 2009 10:21 AM
To: Chase, John
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] COPY BINARY 8.3 to 8.4 timestamp incorrect
"Chase, Joh
"Chase, John" writes:
> I am working on upgrading from 8.3.7 to 8.4.1. One of the functions of
> our application is to "export" and "import" data, and to accomplish this
> I've written some functions that use COPY ... TO ... BINARY and COPY ...
> FROM ... BINARY. In testing the upgrade to 8.4.1 I
that's because by default 8.4 uses integer timestamps, instead of whatever
8.3 was using.
and you pretty much use something, that is suppose to be only used within
the scope of the same version and hardware type (and potentially even
build).
Nathaniel writes:
> When using PQputCopyData and PQgetCopyData to send and receive binary data
> from postgres, would you include/expect headers and trailers (as well as the
> tuples themselves) as you would in a binary file named 'file_name' if you
> were executing the SQL "COPY BINARY table_n
Peter Headland wrote:
> As a general comment, I18N/L10N is a hairy enough topic that it merits
> its own heading in any commands where it is an issue.
I agree, this seems a good idea because people is often confused by
this.
--
Alvaro Herrerahttp://www.CommandPro
2009 11:06
To: Peter Headland
Cc: pgsql-general@postgresql.org; Tom Lane
Subject: Re: [GENERAL] COPY command character set
- "Peter Headland" wrote:
> > The COPY command reference page saith
> >
> >Input data is interpreted according to the current client
> e
ontributor...
--
Peter Headland
Architect
Actuate Corporation
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, September 10, 2009 11:13
To: Peter Headland
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] COPY command character set
"Peter Headla
"Peter Headland" writes:
> How about my suggestion to add a means (extend COPY syntax) to specify
> encoding explicitly and handle UTF lead bytes - would that be of
> interest?
There are no lead bytes in UTF-8, and we make no pretense of handling
UTF-16, so I don't think we'd be interested in som
- "Peter Headland" wrote:
> > The COPY command reference page saith
> >
> >Input data is interpreted according to the current client
> encoding,
> >and output data is encoded in the the current client encoding,
> even
> >if the data does not pass through the client but is read fr
yntax) to specify
encoding explicitly and handle UTF lead bytes - would that be of
interest?
--
Peter Headland
Architect
Actuate Corporation
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, September 10, 2009 10:38
To: Peter Headland
Cc: pgsql-general@postgresql
"Peter Headland" writes:
>> set client_encoding = 'utf8';
>> copy from stdin/to stdout;
> What if I want to do this on the server side (because it's much, much
> faster)? Does COPY use the default encoding of the database? If not,
> what?
> If this is a restrictive as it appears, and there are n
and
Architect
Actuate Corporation
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Wednesday, September 09, 2009 19:14
To: Peter Headland
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] COPY command character set
"Peter Headland" writes:
> The document
"Peter Headland" writes:
> The documentation of the COPY command does not state what character
> set(s) are recognized or written. I need to import and export UTF-8
> data; how can I do that?
set client_encoding = 'utf8';
copy from stdin/to stdout;
regards, tom lane
--
On Fri, Aug 7, 2009 at 12:33 PM, Tom Lane wrote:
> BTW, the "SSL renegotiation failure" bit
> suggests that it could have been an OpenSSL bug not a real network
> lossage, so you might want to see how up-to-date your openssl libraries
> are.
Thanks for your comments, Tom. The operation seems more
I wrote:
> Hmm, so it looks like the connection dropped and libpq failed to
> recognize that, or maybe libpq was okay but psql needs to check a bit
> more carefully here. I'll take a look.
I could not reproduce this problem in testing, but after eyeballing
the code awhile I have a theory. It loo
Neil Best writes:
> Tom Lane-2 wrote:
>> Hmm. It looks like psql could get into an infinite loop if the server
>> failed to exit COPY IN mode for some reason, but it's not at all clear
>> how that could happen (or what to do about it). What server version
>> and what psql version is this? What
Tom Lane-2 wrote:
>
> Hmm. It looks like psql could get into an infinite loop if the server
> failed to exit COPY IN mode for some reason, but it's not at all clear
> how that could happen (or what to do about it). What server version
> and what psql version is this? What does the server's l
Neil Best writes:
> psql:copy.sql:8059525: \copy: unexpected response (4)
> psql:copy.sql:8059525: \copy: unexpected response (4)
> psql:copy.sql:8059525: \copy: unexpected response (4)
> psql:copy.sql:8059525: \copy: unexpected response (4)
> psql:copy.sql:8059525: \copy: unexpected response (4)
On Mon, Aug 03, 2009 at 01:18:06PM -0500, erobles wrote:
> Maybe the error is \c because '\c' is used to connect to another
> database.
> try the same line without '\' only :
> copy gisp from d:/projects/gisp/gisp.csv' delimiters ',';
\copy is a special command in psql that does a cop
On Mon, Aug 03, 2009 at 01:25:56PM -0400, Mark Watson wrote:
> Andrew Maracini wrote:
> >GISCI# \copy gisp from 'd:/projects/gisp/gisp.csv' delimiter ','
>
> If this is the case, exporting the
> City/state field wrapped in quotation marks should do the trick
You'll want to use the real CSV parser
Mark Watson wrote:
*>De :* pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] *De la part de* Andrew
Maracini
>*Envoyé :* 3 août 2009 11:46
>*À :* pgsql-general@postgresql.org
>*Objet :* [GENERAL] \copy command error
>
>hi,
>
>I can't seem to get the \copy comm
>De : pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] De la part de Andrew Maracini
>Envoyé : 3 août 2009 11:46
>À : pgsql-general@postgresql.org
>Objet : [GENERAL] \copy command error
>
>hi,
>
>I can't seem to get the \copy command to work.
>
>Here's my syntax:
>
Andreas wrote on 17.07.2009 20:06:
Hi,
I'd like to read a csv file into PG 8.4.
COPY relations FROM E'd:\\relations.csv' CSV HEADER;
It throws (translated):
ERROR: can't open file >>d:\relations.csv<< for reading
file or directory not found
Try
COPY relations FROM 'd:/relations.csv' CSV HEAD
hmm, I was shelling out and using psql and piping the data to another
file. Not using the dbi stuff with perl.
Guess i can use a regular expression and review the link you sent me
and escape them my self.
Don't *ahem* quote me on this as I haven't been using Perl for a while
but it should
Chris Worley wrote:
...
For example, if I create a
table with a single bytea column called "foo" and insert the a record with
value "^F^O^O" then dump it, the dump will have the following:
COPY byteatest (foo) FROM stdin;
\\006\\017\\017
\.
How does pg_dump and pg_restonre handle everyth
On Tue, Apr 21, 2009 at 1:39 PM, Steve Crawford
wrote:
> Chris Worley wrote:
>>
>> Hello,
>>
>> I get the following error when running a sql script containing a COPY
>> command:
>>
>> ERROR: invalid byte sequence for encoding "UTF8": 0xff...
>>
>> The data I have contains binary data from a tcp d
Chris Worley wrote:
Hello,
I get the following error when running a sql script containing a COPY command:
ERROR: invalid byte sequence for encoding "UTF8": 0xff...
The data I have contains binary data from a tcp dump
Does anybody know how the dump pulls a column with binary data? It is
That's a dead link for me.
-Original Message-
From: Alvaro Herrera [mailto:alvhe...@commandprompt.com]
Sent: Monday, April 06, 2009 12:42 PM
To: Chris Spotts
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] copy from with trigger
Chris Spotts escribió:
Chris Spotts escribió:
> Well that's a bummer, ok. Thanks.
See also
http://archives.postgresql.org/message-id/20090406173912.GB4525%40alvh.no-ip.org
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 suppo
06, 2009 12:42 PM
> To: Chris Spotts
> Cc: 'Tom Lane'; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] copy from with trigger
>
> Chris Spotts escribió:
> > Well that's a bummer, ok. Thanks.
>
> See also
>
> http://archives.postgresql.org/mes
Well that's a bummer, ok. Thanks.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Sunday, April 05, 2009 10:27 PM
To: Chris spotts
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] copy from with trigger
Chris spotts writes:
> I'm trying to co
Chris spotts writes:
> I'm trying to copy from a tab delimited file. The dates inside the file
> are Unix timestamp style dates.
> I thought the following script would do the trick, but it just gives me
> an error saying
> ERROR: invalid input syntax for type timestamp: "1238736600"
> CONTEXT:
On 17/03/2009 15:28, Ivano Luberti wrote:
> I'm sorry, you are right that is the problem
> I had interpreted that as the file should reside on the same machine
> where pgAdmin (or another client) runs , not the server.
>
> Thank you again
You're welcome! That actually cost me a half-hour or so of
I'm sorry, you are right that is the problem
I had interpreted that as the file should reside on the same machine
where pgAdmin (or another client) runs , not the server.
Thank you again
Raymond O'Donnell ha scritto:
> On 17/03/2009 15:04, Ivano Luberti wrote:
>
>> Thanks but it keeps on not
201 - 300 of 639 matches
Mail list logo
