Functions with COPY

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Functions with COPY
Date: 2003-11-27 14:15:20
Message-ID: 20031127141520.GC24094@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Consider the following input data:
1234,24.50,10-Jan-2003,10/1/03,10-01-2003,hiall

The interpretation for the numbers is:
1234 = 12.34, 24.50 = 24.50
The interpretation for the dates is:
January 10th, 2003, October 1st, 2003, October 1st, 2003

I don't believe it's possible, currently, to correctly import this
data with copy. I'm not sure the date fields would even be accepted
as date fields. It'd be nice if this could be made to work. From a
user standpoint consider:

copy blah (
to_number(cost,'99V99'), -- I think that's right?
to_number(cost2,'99.99'),
to_date(install_date,'DD-Mon-YYYY'),
to_date(invoice_date,'MM/DD/YY'),
to_date(bill_date,'MM-DD-YYYY'),
service_type) from stdin;

Perhaps the actual syntax would be different, but the idea is there,
be able to specify a function with arguments to handle the
conversion from the text to the resulting data type in the table.
Right now casting is done but that casting has to be expected to
work for all input formats for each data type cast and that just
isn't reasonable to try and force something to do. Instead, I
believe, the number of input formats accepted has been limited.

Now, that isn't an actual data set I have to deal with, but it's a
good illustration of the problem I've had with some of my data sets,
mainly with the date fields though there is one data set that has the
problem of having an implied decimal point.

Thanks,

Stephen

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruno Wolff III 2003-11-27 14:21:25 Re: Functions with COPY
Previous Message Teodor Sigaev 2003-11-27 14:13:59 about explain analyze