pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedNULL
18+ messages / 10 participants
[nested] [flat]
* NULL
@ 1999-11-15 19:07 Goran Thyni <goran@kirra.net>
0 siblings, 2 replies; 18+ messages in thread
From: Goran Thyni @ 1999-11-15 19:07 UTC (permalink / raw)
To: pgsql-sql
How about this according to SQL standard:
CREATE TABLE x { y integer NULL };
It suppose to mean that NULLs are explicitly allowed in
this field.
Is this required by SQL-92?
TIA,
--
-----------------
Göran Thyni
On quiet nights you can hear Windows NT reboot!
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-15 19:23 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Goran Thyni <goran@kirra.net>
1 sibling, 1 reply; 18+ messages in thread
From: Bruce Momjian @ 1999-11-15 19:23 UTC (permalink / raw)
To: Goran Thyni <goran@kirra.net>; +Cc: pgsql-sql
[Charset iso-8859-1 unsupported, filtering to ASCII...]
>
> How about this according to SQL standard:
>
> CREATE TABLE x { y integer NULL };
>
> It suppose to mean that NULLs are explicitly allowed in
> this field.
> Is this required by SQL-92?
If I remember correctly, only NOT NULL is supported by SQL-92. Thomas
talked about adding support for it in some limited cases for 7.0. There
are shift/reduce cases if it were allowed everywhere.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-15 19:57 Bruce Stephens <bruce@cenderis.demon.co.uk>
parent: Goran Thyni <goran@kirra.net>
1 sibling, 1 reply; 18+ messages in thread
From: Bruce Stephens @ 1999-11-15 19:57 UTC (permalink / raw)
To: pgsql-sql
Goran Thyni <goran@kirra.net> writes:
> How about this according to SQL standard:
>
> CREATE TABLE x { y integer NULL };
>
> It suppose to mean that NULLs are explicitly allowed in
> this field.
> Is this required by SQL-92?
No, it's not required. This came up before with the examples from
"The Practical SQL Handbook". It would be nice to allow it, but there
was some reason why to do so would be non-trivial, which I forget.
Anyway, it's not in SQL-92.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-15 23:48 Jan Wieck <wieck@debis.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: wieck@debis.com @ 1999-11-15 23:48 UTC (permalink / raw)
To: pgman@candle.pha.pa.us; +Cc: goran@kirra.net; pgsql-sql
Bruce Momjian wrote:
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> >
> > How about this according to SQL standard:
> >
> > CREATE TABLE x { y integer NULL };
> >
> > It suppose to mean that NULLs are explicitly allowed in
> > this field.
> > Is this required by SQL-92?
>
> If I remember correctly, only NOT NULL is supported by SQL-92. Thomas
> talked about adding support for it in some limited cases for 7.0. There
> are shift/reduce cases if it were allowed everywhere.
Hmmm,
I can't see any shift/reduce conflicts if I place a
| NULL_P
case into the ColConstraintElem: definition right between the
| DEFAULT b_expr
and
| NOT NULL_P
cases. Could it be that this reason is out of date?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-16 00:50 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jan Wieck <wieck@debis.com>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 1999-11-16 00:50 UTC (permalink / raw)
To: wieck@debis.com; +Cc: pgman@candle.pha.pa.us; goran@kirra.net; pgsql-sql
wieck@debis.com (Jan Wieck) writes:
> I can't see any shift/reduce conflicts if I place a
> | NULL_P
> case into the ColConstraintElem: definition right between the
> | DEFAULT b_expr
> and
> | NOT NULL_P
> cases. Could it be that this reason is out of date?
Could be. I remember tweaking the ColConstraint grammar to avoid
shift-reduce conflicts with NOT NULL, and it might be that that got
rid of the problem with NULL as well.
It's still not legal under the SQL92 spec, though, and I'd hate to see
us give up anything else in order to allow a content-free NULL spec to
be added...
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-16 13:37 jose soares <jose@sferacarta.com>
parent: Bruce Stephens <bruce@cenderis.demon.co.uk>
0 siblings, 2 replies; 18+ messages in thread
From: jose soares @ 1999-11-16 13:37 UTC (permalink / raw)
To: Bruce Stephens <bruce@cenderis.demon.co.uk>; +Cc: pgsql-sql
Bruce Stephens ha scritto:
> Goran Thyni <goran@kirra.net> writes:
>
> > How about this according to SQL standard:
> >
> > CREATE TABLE x { y integer NULL };
> >
> > It suppose to mean that NULLs are explicitly allowed in
> > this field.
> > Is this required by SQL-92?
>
> No, it's not required. This came up before with the examples from
> "The Practical SQL Handbook". It would be nice to allow it, but there
> was some reason why to do so would be non-trivial, which I forget.
> Anyway, it's not in SQL-92.
>
> ************
Sorry, I don't understand why we need this feature. This is completely out
of standard.
What's that mean ?
- Is it a constraint to allow only NULL values ? (unuseful)
- If this is a default value we already have this in:
CREATE TABLE table1 (field1 int DEFAULT NULL);
- According with SQL-92 every column can store a NULL value by default
unless one specify a NOT NULL constraint for the column.
José
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-16 14:16 Jan Wieck <wieck@debis.com>
parent: jose soares <jose@sferacarta.com>
1 sibling, 1 reply; 18+ messages in thread
From: wieck@debis.com @ 1999-11-16 14:16 UTC (permalink / raw)
To: jose@sferacarta.com; +Cc: bruce@cenderis.demon.co.uk; pgsql-sql
> > > It suppose to mean that NULLs are explicitly allowed in
> > > this field.
> > > Is this required by SQL-92?
> >
> > No, it's not required. This came up before with the examples from
> > "The Practical SQL Handbook". It would be nice to allow it, but there
> > was some reason why to do so would be non-trivial, which I forget.
> > Anyway, it's not in SQL-92.
> >
> Sorry, I don't understand why we need this feature. This is completely ou=
> t
> of standard.
>
> What's that mean ?
>
> - Is it a constraint to allow only NULL values ? (unuseful)
Useless? I NEED IT - URGENT - NOW - YESTERDAY.
Then I could create my tables with all required fields for
the future, but prevent that someone stores data in them
until I drop the constraint.
I vote for this :-)
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-17 13:56 jose soares <jose@sferacarta.com>
parent: Jan Wieck <wieck@debis.com>
0 siblings, 1 reply; 18+ messages in thread
From: jose soares @ 1999-11-17 13:56 UTC (permalink / raw)
To: Jan Wieck <wieck@debis.com>; +Cc: bruce@cenderis.demon.co.uk; pgsql-sql
Jan Wieck ha scritto:
> > > > It suppose to mean that NULLs are explicitly allowed in
> > > > this field.
> > > > Is this required by SQL-92?
> > >
> > > No, it's not required. This came up before with the examples from
> > > "The Practical SQL Handbook". It would be nice to allow it, but there
> > > was some reason why to do so would be non-trivial, which I forget.
> > > Anyway, it's not in SQL-92.
> > >
> > Sorry, I don't understand why we need this feature. This is completely ou=
> > t
> > of standard.
> >
> > What's that mean ?
> >
> > - Is it a constraint to allow only NULL values ? (unuseful)
>
> Useless? I NEED IT - URGENT - NOW - YESTERDAY.
>
> Then I could create my tables with all required fields for
> the future, but prevent that someone stores data in them
> until I drop the constraint.
Maybe I miss something here, Jan...I think you don't need such thing to do this
kind of work.
To drop the constraint you have:
1) download the table
2) modify the table structure (without constraint NULL)
3) re-create the table
4) reload it again.
You have the same effect as:
1) download the table
2) add new filelds to table structure
3) re-create the table
4) reload it again
...but, if want these fields from the begining you may create a CHECK contraint
for the field, like:
CREATE TABLE distributors (
did DECIMAL(3),
name VARCHAR(40),
avoid INTEGER
CONSTRAINT con1 CHECK (avoid is NULL)
);
insert into distributors values (33,'PIPPO',123);
ERROR: ExecAppend: rejected due to CHECK constraint con1
insert into distributors values (33,'PIPPO',NULL);
INSERT 1484300 1
select * from distributors;
did|name |avoid
---+-----+-----
33|PIPPO|
(1 row)
...and this is SQL-92 Standard ;)
José
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-17 18:31 Jan Wieck <wieck@debis.com>
parent: jose soares <jose@sferacarta.com>
0 siblings, 0 replies; 18+ messages in thread
From: wieck@debis.com @ 1999-11-17 18:31 UTC (permalink / raw)
To: jose@sferacarta.com; +Cc: wieck@debis.com; bruce@cenderis.demon.co.uk; pgsql-sql
> Jan Wieck ha scritto:
>
> > > - Is it a constraint to allow only NULL values ? (unuseful)
> >
> > Useless? I NEED IT - URGENT - NOW - YESTERDAY.
>
> Maybe I miss something here, Jan...
Yepp - my smiley on the last line.
It wasn't a serious comment. More a joke and I really mean
that such a definition is absolutely not needed. Maybe I'm
writing too much between the lines.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-24 15:08 Bruce Stephens <bruce@cenderis.demon.co.uk>
parent: jose soares <jose@sferacarta.com>
1 sibling, 0 replies; 18+ messages in thread
From: Bruce Stephens @ 1999-11-24 15:08 UTC (permalink / raw)
To: pgsql-sql
jose soares <jose@sferacarta.com> writes:
> Bruce Stephens ha scritto:
> > No, it's not required. This came up before with the examples from
> > "The Practical SQL Handbook". It would be nice to allow it, but there
> > was some reason why to do so would be non-trivial, which I forget.
> > Anyway, it's not in SQL-92.
> - According with SQL-92 every column can store a NULL value by default
> unless one specify a NOT NULL constraint for the column.
Yes. NULL would just mean that NULLs are permitted. So it's not
required, obviously (since this is the default).
However, many books recommend that you should generally not allow
NULLs: thus, if you force yourself to explicitly say "NULL" or "NOT
NULL", that ought to be a prompt to consider the issue (and you can
spot cases which you may not have thought about by the absence of
either). I imagine that's why "The Practical SQL Handbook" suggests
it.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-30 03:13 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 18+ messages in thread
From: Bruce Momjian @ 1999-11-30 03:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jan Wieck <wieck@debis.com>; goran@kirra.net; pgsql-sql
> wieck@debis.com (Jan Wieck) writes:
> > I can't see any shift/reduce conflicts if I place a
> > | NULL_P
> > case into the ColConstraintElem: definition right between the
> > | DEFAULT b_expr
> > and
> > | NOT NULL_P
> > cases. Could it be that this reason is out of date?
>
> Could be. I remember tweaking the ColConstraint grammar to avoid
> shift-reduce conflicts with NOT NULL, and it might be that that got
> rid of the problem with NULL as well.
>
> It's still not legal under the SQL92 spec, though, and I'd hate to see
> us give up anything else in order to allow a content-free NULL spec to
> be added...
OK, I assume we are going to dis-allow NULL as a column constraint. We
could allow it but emmit a notice.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-30 16:12 Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 18+ messages in thread
From: Ross J. Reedstrom @ 1999-11-30 16:12 UTC (permalink / raw)
To: pgsql-sql
On Mon, Nov 29, 1999 at 10:13:59PM -0500, Bruce Momjian wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > wieck@debis.com (Jan Wieck) writes:
> > > I can't see any shift/reduce conflicts if I place a
> > > | NULL_P
> > > case into the ColConstraintElem: definition right between the
> > > | DEFAULT b_expr
> > > and
> > > | NOT NULL_P
> > > cases. Could it be that this reason is out of date?
> >
> > Could be. I remember tweaking the ColConstraint grammar to avoid
> > shift-reduce conflicts with NOT NULL, and it might be that that got
> > rid of the problem with NULL as well.
> >
> > It's still not legal under the SQL92 spec, though, and I'd hate to see
> > us give up anything else in order to allow a content-free NULL spec to
> > be added...
>
> OK, I assume we are going to dis-allow NULL as a column constraint. We
> could allow it but emmit a notice.
My recollection of this thread was that no one found any reason to
dis-allow NULL as a column (pseudo)constraint, other than it not being
in the SQL92 standard. In particular, I understood Jan to say that he
tried it, and received no shift/reduce conflicts from flex. I think we
all agree with Tom that there's no need for it, so we shouldn't give up
anything else to get it, but several people mentioned having it easied
porting from Sybase, or some other commercial db, where the machine
generated DDL dumps include the NULL constraints. So, class it with the
other compatability hacks, and include it, perhaps?
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-30 16:27 Peter Eisentraut <e99re41@DoCS.UU.SE>
parent: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
1 sibling, 1 reply; 18+ messages in thread
From: Peter Eisentraut @ 1999-11-30 16:27 UTC (permalink / raw)
To: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>; +Cc: pgsql-sql
On Tue, 30 Nov 1999, Ross J. Reedstrom wrote:
> My recollection of this thread was that no one found any reason to
> dis-allow NULL as a column (pseudo)constraint, other than it not being
> in the SQL92 standard. In particular, I understood Jan to say that he
That's a pretty strong reason, in absence of any other good ones. The
product is called PostgreSQL and not PostgreSybase or whatever. We
shouldn't have to follow other vendors' questionable decisions. It's not
really that hard to prepare any incompatible dumps you might have.
> tried it, and received no shift/reduce conflicts from flex. I think we
> all agree with Tom that there's no need for it, so we shouldn't give up
> anything else to get it, but several people mentioned having it easied
> porting from Sybase, or some other commercial db, where the machine
> generated DDL dumps include the NULL constraints. So, class it with the
> other compatability hacks, and include it, perhaps?
>
> Ross
>
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-30 17:48 Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
parent: Peter Eisentraut <e99re41@DoCS.UU.SE>
0 siblings, 0 replies; 18+ messages in thread
From: Ross J. Reedstrom @ 1999-11-30 17:48 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-sql
On Tue, Nov 30, 1999 at 05:27:33PM +0100, Peter Eisentraut wrote:
> On Tue, 30 Nov 1999, Ross J. Reedstrom wrote:
>
<snipped me saying NULL constraint not in SQL92 standard>
>
> That's a pretty strong reason, in absence of any other good ones. The
> product is called PostgreSQL and not PostgreSybase or whatever. We
> shouldn't have to follow other vendors' questionable decisions. It's not
> really that hard to prepare any incompatible dumps you might have.
Really? can you give me an awk or sed pattern that easily disambiguates the
use of NULL as a pseudo column constraint from all of its other uses? I
probably can, but that's not useful if the code is being generated on the
fly by some commerical tool, is it?
My feeling on PostgreSQL, SQL standards, and vendor specific compatibility
options is: "be generous with what you accept, strict with what you
create" or something to that effect. We already have a number of vendor
extension compatiblity features in place[1]. Should all of those be ripped
out as well? If this accepting NULL pseudo constrains _costs us nothing_,
why not do it? I agree that implementing missing SQL92 standard features
is more important, and if this NULL actually interfered with anything
else, I'd see your point: straight to the bit bucket with it. But I don't
understand the resistance to a costless extension. The SQL standards
are certainly not holy writ, especially in regards to what they leave out.
Ross
[1] at least, I _think_ we do. Can't seem to list them, right off hand. I
do know a number of cases where ambigous wording in the standard has
been settled by asking "how do the other DBMSs do it?" As in "What will
an experienced DBA expect?"
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-30 18:07 Tom Lane <tgl@sss.pgh.pa.us>
parent: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
1 sibling, 1 reply; 18+ messages in thread
From: Tom Lane @ 1999-11-30 18:07 UTC (permalink / raw)
To: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>; +Cc: pgsql-sql
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> My recollection of this thread was that no one found any reason to
> dis-allow NULL as a column (pseudo)constraint, other than it not being
> in the SQL92 standard. In particular, I understood Jan to say that he
> tried it, and received no shift/reduce conflicts from flex. I think we
> all agree with Tom that there's no need for it, so we shouldn't give up
> anything else to get it, but several people mentioned having it easied
> porting from Sybase, or some other commercial db, where the machine
> generated DDL dumps include the NULL constraints. So, class it with the
> other compatability hacks, and include it, perhaps?
My concern about this is not so much whether it would work at the moment
as whether it will be a nasty limitation in the future. Once we start
allowing NULL as a column constraint we will get justifiable complaints
if we take it out again. But because of SQL's rather silly decision
not to put any punctuation between column constraint clauses, anything
that can start a column constraint clause can't also be a valid entry
in an expression. Consider
CREATE TABLE foo (field1 int DEFAULT 2 ++ NULL)
Here, the grammar cannot figure out whether the default expression is
"2 ++ NULL" (with ++ an infix operator) or "2 ++" (++ a postfix operator)
and NULL a separate constraint clause.
We currently work around this for NOT NULL column constraints by making
default expressions be b_expr's, which don't include the boolean
operators --- if you need a boolean operator in a default expression,
you have to put parentheses around the whole thing. I don't want to
have to restrict b_expr further in order to support NULL column
constraints.
I think the only reason Jan's test worked is that NULL as an expression
value is handled in a rather hacky way --- there's a separate
a_expr_or_null nonterminal --- and I've been intending to try to
eliminate that kluge. Right now, things like this draw parse errors:
select null::text;
ERROR: parser: parse error at or near "::"
select (cast null as text);
ERROR: parser: parse error at or near "null"
because NULL isn't parsed as a fully valid expression value. I'd
rather try to clean that up, because it is (a) useful and (b) legal SQL,
rather than make the world safe for a column constraint phrase that
is (a) useless and (b) not legal SQL.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] NULL
@ 1999-11-30 19:09 Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 18+ messages in thread
From: Ross J. Reedstrom @ 1999-11-30 19:09 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-sql
On Tue, Nov 30, 1999 at 01:07:22PM -0500, Tom Lane wrote:
<snipped excellent description about the problem with NULL as a
column constraint>
Ah, now I understand. And as I said, if it would cause a problem, now or
in the forseeable future, skip it. I propose dropping Tom's explanation
(or a summary of it) into the FAQ. how about :
------------
Q: Why doesn't PostgreSQL support NULL as a column constraint?
Short A: Because it's not in the SQL92 standard.
Long A:
Because of SQL's rather silly decision not to put any punctuation between
column constraint clauses, anything that can start a column constraint
clause can't also be a valid entry in an expression. Consider
CREATE TABLE foo (field1 int DEFAULT 2 ++ NULL)
Here, the grammar cannot figure out whether the default expression is
"2 ++ NULL" (with ++ an infix operator) or "2 ++" (++ a postfix operator)
and NULL a separate constraint clause.
------------
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: NULL
@ 2000-10-24 18:31 Sandis Jerics <sandis@mediaparks.lv>
0 siblings, 1 reply; 18+ messages in thread
From: Sandis Jerics @ 2000-10-24 18:31 UTC (permalink / raw)
To: pgsql-novice@postgresql.org; pgsql-sql
Hello,
how must i write a NULL value in a text file for the \copy command to
understand it?
NULL, \0 doesnt work..
how must i write a boolean value in a text file for the \copy command to
understand it?
t doesnt work, however in a file written by /copy command it looks as
t or f ..
tried to search archives, but it seems deadly slow...
Thanks in advance,
sandis
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] Re: NULL
@ 2000-10-24 20:39 Mark Volpe <volpe.mark@epamail.epa.gov>
parent: Sandis Jerics <sandis@mediaparks.lv>
0 siblings, 0 replies; 18+ messages in thread
From: Mark Volpe @ 2000-10-24 20:39 UTC (permalink / raw)
To: Sandis Jerics <sandis@mediaparks.lv>; +Cc: pgsql-novice@postgresql.org; pgsql-sql
\N is normally used to represent NULL in a text file, however
you can change that to another string (or an empty string) using
COPY FROM ... WITH NULL AS
Mark
Sandis Jerics wrote:
>
> Hello,
>
> how must i write a NULL value in a text file for the \copy command to
> understand it?
> NULL, \0 doesnt work..
>
> how must i write a boolean value in a text file for the \copy command to
> understand it?
> t doesnt work, however in a file written by /copy command it looks as
> t or f ..
>
> tried to search archives, but it seems deadly slow...
>
> Thanks in advance,
> sandis
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2000-10-24 20:39 UTC | newest]
Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-11-15 19:07 NULL Goran Thyni <goran@kirra.net>
1999-11-15 19:23 ` Bruce Momjian <pgman@candle.pha.pa.us>
1999-11-15 23:48 ` Jan Wieck <wieck@debis.com>
1999-11-16 00:50 ` Tom Lane <tgl@sss.pgh.pa.us>
1999-11-30 03:13 ` Bruce Momjian <pgman@candle.pha.pa.us>
1999-11-30 16:12 ` Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
1999-11-30 16:27 ` Peter Eisentraut <e99re41@DoCS.UU.SE>
1999-11-30 17:48 ` Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
1999-11-30 18:07 ` Tom Lane <tgl@sss.pgh.pa.us>
1999-11-30 19:09 ` Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
1999-11-15 19:57 ` Bruce Stephens <bruce@cenderis.demon.co.uk>
1999-11-16 13:37 ` jose soares <jose@sferacarta.com>
1999-11-16 14:16 ` Jan Wieck <wieck@debis.com>
1999-11-17 13:56 ` jose soares <jose@sferacarta.com>
1999-11-17 18:31 ` Jan Wieck <wieck@debis.com>
1999-11-24 15:08 ` Bruce Stephens <bruce@cenderis.demon.co.uk>
2000-10-24 18:31 Re: NULL Sandis Jerics <sandis@mediaparks.lv>
2000-10-24 20:39 ` Mark Volpe <volpe.mark@epamail.epa.gov>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox