How to setup default value "0000-00-00" for "date" type under PostgreSQL?

[Emi Lu]

Hello all,

I have a question about "date" & "timestamp" types in PostgreSQL. I want
to setup the default value '0000-00-00' and "0000-00-00 00:00:00" for
them. However, it seems that PostgreSQL does not support it. Could
someone helps me please?

The example table:

T1 (col1 varchar(7) not null,
col2 varchar(4) not null,
col3 date not null,
col 4 varchar(3),
primary key(col1, col2, col3)
)
In my design model, "col3" has to be one of the primary key part. Since
at the beginning of the data population, we do not know the value of
"col3"; values for "col3" are input throught GUI. Therefore, when I use
MySQL, the default values I gave is "0000-00-00". However, after I
migrate to postgreSQL, I could not setup the default values as
"0000-00-00" any more. Could somebody help me about it please? I really
want to know how I can save '0000-00-00' as the default value for "date"
and "timestamp" types.

Thanks a lot!
Emi Lu


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Karsten Hilbert]

> I really

want to know how I can save '0000-00-00' as the default value for "date"
and "timestamp" types.

You can not. They are invalid dates.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Christian Kratzer]

On Wed, 18 Aug 2004, Emi Lu wrote:

Hello all,

I have a question about "date" & "timestamp" types in PostgreSQL. I want to
setup the default value '0000-00-00' and "0000-00-00 00:00:00" for them.
However, it seems that PostgreSQL does not support it. Could someone helps me
please?

how about using NULL ? You say the correct value is still undefined so
NULL should be right on the spot.

Greetings
Christian

--
Christian Kratzer [e-mail]
CK Software GmbH http://www.cksoft.de/
Phone: [phone] Fax: [phone]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Richard Huxton]

Emi Lu wrote:

Hello all,

I have a question about "date" & "timestamp" types in PostgreSQL. I want
to setup the default value '0000-00-00' and "0000-00-00 00:00:00" for
them. However, it seems that PostgreSQL does not support it. Could
someone helps me please?
PostgreSQL doesn't and almost certainly never will support "0000-00-00"
as a date. That's because it isn't a valid date. You also can't store
13.723, "Hello world" or (12,13) in a date column either.

Where you don't have a valid date to store you should use NULL. This
business of storing zeroes is a horrible MySQL design mistake.
The example table:

T1 (col1 varchar(7) not null,
col2 varchar(4) not null,
col3 date not null,
col 4 varchar(3),
primary key(col1, col2, col3)
)
In my design model, "col3" has to be one of the primary key part. Since
at the beginning of the data population, we do not know the value of
"col3"; values for "col3" are input throught GUI.

If you don't know the value of col3, it can't be part of your primary
key. That's part of the definition of "primary key" and trying to work
around it is what's causing you problems here.

If you have an initial population of data that then needs to have "col3"
set then it sounds like you need two tables T0 with primary-key
(col1,col2) and T1 with (col1,col2,col3) and copy from T0=>T1 as users
supply values. Difficult to say without knowing more about your situation.

HTH
--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Christian Kratzer]

Hi,

On Fri, 20 Aug 2004, Richard Huxton wrote:

Emi Lu wrote:

Hello all,

I have a question about "date" & "timestamp" types in PostgreSQL. I want
to setup the default value '0000-00-00' and "0000-00-00 00:00:00" for
them. However, it seems that PostgreSQL does not support it. Could someone
helps me please?

PostgreSQL doesn't and almost certainly never will support "0000-00-00" as a
date. That's because it isn't a valid date. You also can't store 13.723,
"Hello world" or (12,13) in a date column either.

Where you don't have a valid date to store you should use NULL. This business
of storing zeroes is a horrible MySQL design mistake.

which is because the last time when I last used mysql it did not support
NULLs in indexed columns (at least not in myisam tables).

The workaround was to use something else like 0 to represent undefined
values.... Horrible ...

Greetings
Christian

--
Christian Kratzer [e-mail]
CK Software GmbH http://www.cksoft.de/
Phone: [phone] Fax: [phone]

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Michal Taborsky]

Richard Huxton wrote:

Where you don't have a valid date to store you should use NULL. This
business of storing zeroes is a horrible MySQL design mistake.

Well, yes and no. It certainly is a design mistake and introduces
incosistency into the database, but after I was bitten several times by
NULL values I'd go for solution like this any day. Let me explain.

We had a table of messages, which was inserted to randomly and every few
minutes we'd walk through the unprocessed messages and perform some work
on them. I, trying to have the database as clean as possible, used this
table definition (simplified):

messages (
id serial,
data text,
arrived timestamp default now,
processed timestamp)

So after the message arrived, it had the processed field set to null,
which was perfectly consistent and represented what it realy was--an
unknown value.

We'd then simply SELECT * FROM messages WHERE processed IS NULL and were
happy ever after, only to realise after the table had grown to few
thousands rows, that the SELECT took ages, because the system had to
perform seqscan. Aha! So we added an index on processed, because common
sense told me, that as long as there are 100k rows and only 10 of them
are NULL, the index would be very selective and therefore useful.

I guess you know where it ends--the index is not used for IS [NOT] NULL
expressions. The obvious workaround was to add DEFAULT value to
"processed" in form of kind of anchor (we used '-infinity') and then do
SELECT * FROM messages WHERE processed='-infinity'.

Bingo! The thing went 100x faster. So we could choose to have
standards-compliant, very clean database design OR the thing that does
what it's supposed to do in reasonable time. And believe me, it's kind
of difficult to explain to our logistics department that we could have
done the thing to return results in milliseconds instead of 10 secs, but
chose not to for sake of clean design.

It'd be really nice if we didn't have to use such hacks, but hey, life's
inperfect.

And so that this would not be just a literary exercise and to answer
Emi's question--you can't do that, but use some valid date which you are
never going to use for your ordinary data (like the '-infinity', or
1.1.1970 00:00). Just make sure you make a note of it somewhere and my
suggestion is you write a COMMENT ON that column for future generations.

--
Michal Taborsky
http://www.taborsky.cz
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Karsten Hilbert]

> I guess you know where it ends--the index is not used for IS [NOT] NULL

expressions. The obvious workaround was to add DEFAULT value to
"processed" in form of kind of anchor (we used '-infinity')

Wouldn't it have worked to add an index

... WHERE processed IS NULL

and go from there ?

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Jim Wilson]

Michal Taborsky said:

Richard Huxton wrote:

Where you don't have a valid date to store you should use NULL. This
business of storing zeroes is a horrible MySQL design mistake.

Well, yes and no. It certainly is a design mistake and introduces
incosistency into the database, but after I was bitten several times by
NULL values I'd go for solution like this any day. Let me explain.

We had a table of messages, which was inserted to randomly and every few
minutes we'd walk through the unprocessed messages and perform some work
on them. I, trying to have the database as clean as possible, used this
table definition (simplified):

messages (
id serial,
data text,
arrived timestamp default now,
processed timestamp)

So after the message arrived, it had the processed field set to null,
which was perfectly consistent and represented what it realy was--an
unknown value.

We'd then simply SELECT * FROM messages WHERE processed IS NULL and were
happy ever after, only to realise after the table had grown to few
thousands rows, that the SELECT took ages, because the system had to
perform seqscan. Aha! So we added an index on processed, because common
sense told me, that as long as there are 100k rows and only 10 of them
are NULL, the index would be very selective and therefore useful.

I guess you know where it ends--the index is not used for IS [NOT] NULL
expressions. The obvious workaround was to add DEFAULT value to
"processed" in form of kind of anchor (we used '-infinity') and then do
SELECT * FROM messages WHERE processed='-infinity'.

Bingo! The thing went 100x faster. So we could choose to have
standards-compliant, very clean database design OR the thing that does
what it's supposed to do in reasonable time. And believe me, it's kind
of difficult to explain to our logistics department that we could have
done the thing to return results in milliseconds instead of 10 secs, but
chose not to for sake of clean design.

It'd be really nice if we didn't have to use such hacks, but hey, life's
inperfect.

It'd probably be better design to not use the date as a flag. This issue
actually came up for me yesterday with an application that is now being ported
to Postgres. Previously a null "ship date" indicated that an item to be
shipped had not gone yet. I'm adding a flag, not just because of this issue
you describe, but it is also more intuitive for anyone looking at the data
who is unfamiliar with the business logic.

Best,

Jim Wilson
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Bruce Momjian]

Karsten Hilbert wrote:

I guess you know where it ends--the index is not used for IS [NOT] NULL
expressions. The obvious workaround was to add DEFAULT value to
"processed" in form of kind of anchor (we used '-infinity')

Wouldn't it have worked to add an index

... WHERE processed IS NULL

and go from there ?

Yes, you use a partial index. The 8.0beta1 docs mention this:

Indexes are not used for <literal>IS NULL</> clauses by default.
The best way to use indexes in such cases is to create a partial index
using an <literal>IS NULL</> comparison.

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Peter Haworth]

On Fri, 20 Aug 2004 11:12:40 -0400 (EDT), Bruce Momjian wrote:

Yes, you use a partial index. The 8.0beta1 docs mention this:

Indexes are not used for <literal>IS NULL</> clauses by default.
The best way to use indexes in such cases is to create a partial
index using an <literal>IS NULL</> comparison.

Is this because nulls aren't indexed (I'm sure I remember someone
saying that they are, though), or because (null=null) is null rather
than true? If it's the latter, why couldn't an explicit IS NULL test
be allowed to use the index?

--
Peter Haworth pm*@edison.ioppublishing.com
Znqr lbh ybbx

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

"Peter Haworth" <pm*@edison.ioppublishing.com> writes:

... why couldn't an explicit IS NULL test
be allowed to use the index?

It could, if someone cared to puzzle out a way to integrate IS NULL into
the index opclass and access method API infrastructure. Right now all
that stuff assumes that indexable operators are, well, operators (and I
think there are places that assume they must be binary operators, to
boot).

I've looked at this once or twice but always decided that the
bang-for-the-buck ratio was too low compared to other open problems ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Harald Fuchs]

In article <tw*******************@kelcomaine.com>,
"Jim Wilson" <ji**@kelcomaine.com> writes:

It'd probably be better design to not use the date as a flag. This issue
actually came up for me yesterday with an application that is now being ported
to Postgres. Previously a null "ship date" indicated that an item to be
shipped had not gone yet. I'm adding a flag, not just because of this issue
you describe, but it is also more intuitive for anyone looking at the data
who is unfamiliar with the business logic.

Me thinks that's somewhat unclean. Is your shipDate nullable? If
yes, what's the meaning of "shipDate IS NULL"? If no, what do you put
in that field if notYetShipped is true?
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Jim Wilson]

Harald Fuchs said:

In article <tw*******************@kelcomaine.com>,
"Jim Wilson" <ji**@kelcomaine.com> writes:

It'd probably be better design to not use the date as a flag. This issue
actually came up for me yesterday with an application that is now being ported
to Postgres. Previously a null "ship date" indicated that an item to be
shipped had not gone yet. I'm adding a flag, not just because of this issue
you describe, but it is also more intuitive for anyone looking at the data
who is unfamiliar with the business logic.

Me thinks that's somewhat unclean. Is your shipDate nullable? If
yes, what's the meaning of "shipDate IS NULL"? If no, what do you put
in that field if notYetShipped is true?

Actually it would be a boolean "shipped" flag. ShipDate can be whatever you
want. Perhaps even null. All in all it just makes sense to use the boolean
when you need a flag (or integer or char for more than two flag states).

Best,

Jim
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)