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
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 your efforts. But as indicate
Bruce Momjian wrote:
I see that the default NULL for CSV mode is ''. I was hoping the
default was something more special. Right now, by default, comma-comma
is a null and comma-double-quote-double-quote-comma is a zero-length
string. I am thinking there should be a way to set NULL to be either
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> For all those reasons I disallowed use of WITH OIDS for CSV mode.
> While doing OIDs seems atypical, it seems like a reasonable thing that
> CSV should be able to do. Basically, I see no reason to disable it.
I agree. It's an
Andrew Dunstan wrote:
> Yes. What *I* meant was that allowing it was OK with me, and not worth
> arguing over.
OK, thanks.
> Incidentally, the patch looks OK at first glance, and seems to work
> fine, modulo today's little controversies, with this exception:
>
> if (csv_mode)
> {
>
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
While doing OIDs seems atypical, it seems like a reasonable thing that
CSV should be able to do. Basically, I see no reason to disable it.
OK. We have bigger fish to fry ;-)
Uh, sorry, what I meant was that we
Andrew Dunstan wrote:
> >As for setting default values, I think that is a good idea. I suggested
> >a while back. There could be another keyword, DEFAULT, on the COPY FROM
> >command that is used to define a code that will be replaced by the
> >default value (or NULL if there is no default for a co
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
And how would you define "numeric"?
At least the following:
int8
int2
int4
float4
float8
numeric
money
and domains based on them.
Wrong answer, as this excludes user-defined types. CO
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >While doing OIDs seems atypical, it seems like a reasonable thing that
> >CSV should be able to do. Basically, I see no reason to disable it.
> >
> >
> >
>
> OK. We have bigger fish to fry ;-)
Uh, sorry, what I meant was that we should have it
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> And how would you define "numeric"?
> At least the following:
> int8
> int2
> int4
> float4
> float8
> numeric
> money
> and domains based on them.
Wrong answer, as this excludes user-defined types. COPY should not
discrimi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Well, as I indicated we can deal with this in a subsequent round, I
> think. However, here's an idea. We know (or can easily discover) if
> there is a NOT NULL constraint that can apply to the attribute (or
> domain if it is a domain type). If isnull
Bruce Momjian wrote:
While doing OIDs seems atypical, it seems like a reasonable thing that
CSV should be able to do. Basically, I see no reason to disable it.
OK. We have bigger fish to fry ;-)
cheers
andrew
---(end of broadcast)---
TIP 9: th
Andrew Dunstan wrote:
> >
> > I have two open issues. First, CSV should support WITH OIDS, no?
> >
>
> Why on earth would you want to? OIDs only have emaning to postgresql.
> Dumping to/from CSVs should not be seen as an alternative to Postgresql's
> normal text or binary file formats. Rather, it
Bruno Wolff III wrote:
On Tue, Apr 13, 2004 at 06:58:24 -0400,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
One area that we should think about as an enhancement is NOT NULL fields.
As it stands now, we will get what we normally get when we try to insert
a null into a NOT NULL field, namely an e
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"?
At least the following:
int8
int2
int4
float4
float8
numeric
money
and domains based
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"?
I do *not* like putting data-type-specific knowledge into COPY.
regards, tom lane
Andrew Dunstan wrote:
Bruce Momjian said:
Second, I found a problem with NULLs. If I do:
.
test=> create table test (x text, y text);
CREATE TABLE
test=> insert into test values ('', NULL);
INSERT 17221 1
test=>
then this:
test=> copy test to '/tmp/b' with
On Tue, Apr 13, 2004 at 06:58:24 -0400,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> One area that we should think about as an enhancement is NOT NULL fields.
> As it stands now, we will get what we normally get when we try to insert
> a null into a NOT NULL field, namely an error. If the fiel
Bruce Momjian said:
> Second, I found a problem with NULLs. If I do:
> .
>test=> create table test (x text, y text);
>CREATE TABLE
>test=> insert into test values ('', NULL);
>INSERT 17221 1
>test=>
>
> then this:
>
>test=> copy test to '/tmp/b' with
Bruce Momjian said:
>
> OK, here is a new version of the patch that includes the grammar changes
we agreed upon, SGML changes, and \copy support. I will not make any more
changes without contacting you so feel free to make adjustments and repost.
Excellent. Quick work :-) I will test later today
27 matches
Mail list logo
