Re: Date format for bulk copy

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: David Rysdam <drysdam(at)ll(dot)mit(dot)edu>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Date format for bulk copy
Date: 2004-10-14 15:47:49
Message-ID: 20041014154749.GB95346@winnie.fuhr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Oct 13, 2004 at 03:37:14PM -0400, David Rysdam wrote:
> Michael Fuhr wrote:
> >
> >I'd probably choose to extend PostgreSQL rather than hack what
> >already exists, though.
>
> By "extend PostgreSQL" do you mean create a custom input_function for
> timestamp? Are there docs that give hints for replacing the input
> function of an existing type? Someone else replied similarly, but I'm
> afraid I'm not familiar enough with PG to decipher it all.

I'd been thinking about your idea of creating a custom type or
providing a custom input function for a standard type. I've
done simple tests where I updated a type's typinput field in
pg_catalog.pg_type and it worked, but I don't know what problems
that might cause. One thing that comes to mind is that I don't
know if pg_dump/pg_dumpall would recognize such a change for a
standard type. The more I think about it, the less I'm convinced
that it's a good idea.

I like Pierre-Frdric Caillaud's suggestion to have a
filter script query the database for field positions and types
and reformat the fields as appropriate. That would allow the
filter to have knowledge of which fields should be reformatted
without having to program that logic explicitly.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Cain 2004-10-14 16:09:49 Re: creating audit tables
Previous Message Robin Ericsson 2004-10-14 15:30:58 not using index through procedure