Re: ERROR: relation . . . does not exist - Mailing list pgsql-general

From Adrian Klaver
Subject Re: ERROR: relation . . . does not exist
Date
Msg-id 200808281650.55565.aklaver@comcast.net
Whole thread Raw
In response to Re: ERROR: relation . . . does not exist  ("Albretch Mueller" <lbrtchx@gmail.com>)
Responses Re: ERROR: relation . . . does not exist  ("Albretch Mueller" <lbrtchx@gmail.com>)
List pgsql-general
On Thursday 28 August 2008 3:14:01 pm Albretch Mueller wrote:
> On Thu, Aug 28, 2008 at 5:40 PM, Raymond O'Donnell <rod@iol.ie> wrote:
> > You have to create the table first before you can COPY into it.
>
> ~
>  Well, based on how the statement reads I made the wrong assumption of
> thinking that  PG would be smart enough to make ends-meat with the
> data that it gets once you indicate:
> ~
>  1) the header names (to be mapped to column names)
> ~
>  2) the data from which PG could easily figure out the types for each
> column, since it is CSV data

Define easily. A CSV column has fields with 1's and 0's  should that be an
integer field or a boolean field?  A CSV column has a series of text entries
none of which are greater then 25 characters long. Does that mean a datatype
of varchar(25) or is it just an artifact of the data to date? You have a CSV
column with text strings of format 'YYYY/MM/DD' . Do you want them stored as
strings or dates?  I could go on, but the point is that table data types
require some thought on the part of the DBA.

> ~
>  That may/should become a RFE
> ~
>  Thanks
>  lbrtchx
> ~



--
Adrian Klaver
aklaver@comcast.net

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: indexes on functions and create or replace function
Next
From: "Matthew Dennis"
Date:
Subject: Re: indexes on functions and create or replace function