Bruce Momjian wrote:
Here is a new version of the patch. The call to TypeCategory() is gone,
and in its place is a way to force quotes on output, using FORCE. And,
instead of warning about a nullstring going into a NOT NULL column,
there is a new LITERAL capability that does not compare the
Bruce Momjian said:
Andrew Dunstan wrote:
copy mytable to 'mydata.csv' csv force zipcode;
seems OK to me. I'm all in favor of low-tecH solutions where
appropriate. ;-)
Could we have FORCE just force quotes on all values, rather than
allowing a list of columns to be specified? Seems if
Andrew Dunstan wrote:
Bruce Momjian said:
Andrew Dunstan wrote:
copy mytable to 'mydata.csv' csv force zipcode;
seems OK to me. I'm all in favor of low-tecH solutions where
appropriate. ;-)
Could we have FORCE just force quotes on all values, rather than
allowing a list of
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian said:
Andrew Dunstan wrote:
copy mytable to 'mydata.csv' csv force zipcode;
seems OK to me. I'm all in favor of low-tecH solutions where
appropriate. ;-)
Could we have FORCE just force quotes on all values, rather
Andrew Dunstan wrote:
Bruce Momjian wrote:
What about NULL input? Is my warning and promotion to zero-length
string for NOT NULL columns OK?
I know I originally floated this idea or one very like it, but I have
become convinced it is not a good idea after all. The user might
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
What about NULL input? Is my warning and promotion to zero-length
string for NOT NULL columns OK?
I know I originally floated this idea or one very like it, but I have
become
Bruce Momjian wrote:
Richard Huxton wrote:
On Thursday 15 April 2004 15:58, Bruce Momjian wrote:
OK, so we need a list of columns for output with quotes, and a list of
columns where NULL should be changed to zero-length strings.
How about if we use FORCE to force quotes on
Bruce Momjian wrote:
I talked to Andrew on IRC and we went over the open CSV issues.
We talked about how we could do quoting for zipcode in TEXT fields and
not quote true numeric values without hardcoding datatypes into the
system. The most tricky case was NUMERIC vs. TEXT with zipcodes.
Bruce Momjian wrote:
Bruce Momjian wrote:
I talked to Andrew on IRC and we went over the open CSV issues.
We talked about how we could do quoting for zipcode in TEXT fields and
not quote true numeric values without hardcoding datatypes into the
system. The most tricky case was NUMERIC
Bruce Momjian [EMAIL PROTECTED] writes:
I found parse_coerce.c::TypeCategory(), which contains information about
which data type oids are in which grouping, e.g. DATETIME, STRING,
NUMERIC, etc. It seems that function, if called with
pg_type.typbasetype could help determine if quotes should be
Bruce Momjian said:
So, for open CSV items we have:
o add oid dump/reload
There seems to be agreement on this at least. All you need to do is remove
these lines - AFAICS the OID code should be able to be happily non-CSV-
aware.
/*
* Don't allow OIDs in CSV mode
Bruce Momjian [EMAIL PROTECTED] writes:
Particularly, how do we identify a numeric and dates?
We don't, and I'm not convinced that we should. The entire concept is
suspect in a type-agnostic system. In particular, I've really got a
problem with the fact that TypeCategory uses a fixed,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Particularly, how do we identify a numeric and dates?
We don't, and I'm not convinced that we should. The entire concept is
suspect in a type-agnostic system. In particular, I've really got a
problem with the fact that TypeCategory
Andrew Dunstan wrote:
Bruce Momjian said:
So, for open CSV items we have:
o add oid dump/reload
There seems to be agreement on this at least. All you need to do is remove
these lines - AFAICS the OID code should be able to be happily non-CSV-
aware.
/*
* Don't
Bruce Momjian said:
Tom Lane wrote:
TypeCategory is a crock that should have been done away with long ago.
We need to be working to eliminate it, not expand our dependency on
it.
Ah, so do we have any other way to identify the type of field we are
using? Particularly, how do we identify a
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I found parse_coerce.c::TypeCategory(), which contains information about
which data type oids are in which grouping, e.g. DATETIME, STRING,
NUMERIC, etc. It seems that function, if called with
pg_type.typbasetype could help
Andrew Dunstan wrote:
Bruce Momjian said:
Tom Lane wrote:
TypeCategory is a crock that should have been done away with long ago.
We need to be working to eliminate it, not expand our dependency on
it.
Ah, so do we have any other way to identify the type of field we are
using?
17 matches
Mail list logo
