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
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 hel
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 id
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.
>
>/*
>
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 TypeC
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, nonexp
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:
> 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 shou
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 w
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:
> Wow, that is certainly an excellent point. When we import, we know the
> resulting data type, but spreadsheets don't, and rely on the quoting to
> know what to do with the value.
>
> The zipcode is an excellent example. You can't even test for leading
> zeros because then
New version of this patch has been added to the PostgreSQL unapplied
patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Claudio Natoli wrote:
>
>
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >
> >Do we need control for each column? What if we go with preferring NULL
> >for comma-comma, and then print warnings for NOT NULL columns and try
> >the promote. If you want comma-comma to be zero-length string, you can
> >create the column wit
Bruce Momjian wrote:
Do we need control for each column? What if we go with preferring NULL
for comma-comma, and then print warnings for NOT NULL columns and try
the promote. If you want comma-comma to be zero-length string, you can
create the column with NOT NULL, load the file, then ALTER TABL
Andrew Dunstan wrote:
> Again, I think this will break that property. But if that's what it
> takes to be able to import to a table with NOT NULL in at least some
> cases I could live with it. Just. But in the general case it won't work.
> Say you are importing into a table with the following de
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I don't agree about moving this to a client. It is too important for
> > that. Many admin apps and psql need this capability and having it in
> > a client just requires everyone to reinvent the wheel.
>
> So far the only need I've heard of is du
Bruce Momjian wrote:
> I don't agree about moving this to a client. It is too important for
> that. Many admin apps and psql need this capability and having it in
> a client just requires everyone to reinvent the wheel.
So far the only need I've heard of is dumping the data to an
appropriately
Karel Zak said:
> On Tue, Apr 13, 2004 at 10:43:35AM -0400, Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> > Thinking about this some more maybe the right rule would be
>> > "quote all non-numeric non-null values".
>>
>> And how would you define "numeric"?
>
> And don't for
Bruce Momjian said:
> Andrew Dunstan wrote:
>> I don't believe '' should be special, any more than 'fred' should be.
>> As it stands now, NULL 'fred' does say that ,, and '"", are empty
>> strings.
>>
>> >Again, I can assist in making these modifications to the patch.
>> >
>> >
>>
>> I appreciate
On Tue, Apr 13, 2004 at 10:43:35AM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Thinking about this some more maybe the right rule would be "quote
> > all non-numeric non-null values".
>
> And how would you define "numeric"?
And don't forget that number format
20 matches
Mail list logo
