Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, the NULL-pointer test might equally well be coded as an Assert:
> You really think it should be Assert?
I don't feel a need to change it, no. I was just pointing out that
there shouldn't be any way for a user to cause that con
Patch applied.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The exclamation point seems inappropriate. Perhaps "zero-length input"
> >> would be better than "string" also.
>
> >
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The exclamation point seems inappropriate. Perhaps "zero-length input"
> >> would be better than "string" also.
>
> > I copied the other test case:
>
> > if (s == (char *) NULL)
> > elog(ERROR, "pg_
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The exclamation point seems inappropriate. Perhaps "zero-length input"
>> would be better than "string" also.
> I copied the other test case:
> if (s == (char *) NULL)
> elog(ERROR, "pg_atoi: NULL pointer!");
Well, the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > else if (*s == 0)
> > ! elog(ERROR, "pg_atoi: zero-length string!");
>
> The exclamation point seems inappropriate. Perhaps "zero-length input"
> would be better than "string" also.
I copied the other test case:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> else if (*s == 0)
> ! elog(ERROR, "pg_atoi: zero-length string!");
The exclamation point seems inappropriate. Perhaps "zero-length input"
would be better than "string" also.
Otherwise this seems like a reasonable thing to do.
Tom Lane wrote:
> A subsidiary point here is that pg_atoi() explicitly takes a zero-length
> string as valid input of value 0. I think this is quite bogus myself,
> but I don't know why that behavior was put in or whether we'd be breaking
> anything if we tightened it up.
I have attached a patch
[EMAIL PROTECTED] (Neil Conway) writes:
>> leading up to the TODO item that mentions rejecting COPY input rows
>> with the wrong number of fields (rather than silently filling with
>> NULLs as we do now).
> Yeah, I was thinking that too. Now that we have column lists in
> COPY, there is no need t
On Wed, Jul 24, 2002 at 04:23:56PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Neil Conway) writes:
> > This behavior doesn't look right:
>
> It's not, but I believe the correct point of view is that the input
> data is defective and should be rejected. See past discussions
> leading up to the T
[EMAIL PROTECTED] (Neil Conway) writes:
> This behavior doesn't look right:
It's not, but I believe the correct point of view is that the input
data is defective and should be rejected. See past discussions
leading up to the TODO item that mentions rejecting COPY input rows
with the wrong number
This behavior doesn't look right:
nconway=# create table foo (a int default 50, b int default 100);
CREATE TABLE
nconway=# copy foo from stdin;
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>>
>> \.
nconway=# select * from foo;
a | b
---+
11 matches
Mail list logo
