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

**Karsten Hilbert** · Nov 23 '05, 01:43 AM

Re: How to setup default value "0000-00-00" for "date&quot ; type under PostgreSQL?

> I really[color=blue]
> want to know how I can save '0000-00-00' as the default value for "date"
> and "timestamp" types.[/color]
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** · Nov 23 '05, 01:43 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

On Wed, 18 Aug 2004, Emi Lu wrote:
[color=blue]
> 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?[/color]

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

Greetings
Christian

--
Christian Kratzer ck@cksoft.de
CK Software GmbH http://www.cksoft.de/
Phone: +49 7452 889 135 Fax: +49 7452 889 136

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

**Richard Huxton** · Nov 23 '05, 01:43 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

Emi Lu wrote:[color=blue]
> 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?[/color]

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.
[color=blue]
> 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.[/color]

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 majordomo@postg resql.org

**Christian Kratzer** · Nov 23 '05, 01:43 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

Hi,

On Fri, 20 Aug 2004, Richard Huxton wrote:
[color=blue]
> Emi Lu wrote:[color=green]
>> 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?[/color]
>
> 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.[/color]

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 ck@cksoft.de
CK Software GmbH http://www.cksoft.de/
Phone: +49 7452 889 135 Fax: +49 7452 889 136

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

**Michal Taborsky** · Nov 23 '05, 01:43 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

Richard Huxton wrote:[color=blue]
> 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.[/color]

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

Michal Táborský

http://www.taborsky.cz

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

PostgreSQL: PostgreSQL Mailing List Archives

http://archives.postgresql.org

**Karsten Hilbert** · Nov 23 '05, 01:44 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

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

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 majordomo@postg resql.org

**Jim Wilson** · Nov 23 '05, 01:44 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

Michal Taborsky said:
[color=blue]
> Richard Huxton wrote:[color=green]
> > 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.[/color]
>
> 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.[/color]

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 majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

**Bruce Momjian** · Nov 23 '05, 01:44 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

Karsten Hilbert wrote:[color=blue][color=green]
> > 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')[/color]
>
> Wouldn't it have worked to add an index
>
> ... WHERE processed IS NULL
>
> and go from there ?[/color]

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
pgman@candle.ph a.pa.us | (610) 359-1001
+ 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?

PostgreSQL: Not Found

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

**Peter Haworth** · Nov 23 '05, 01:44 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

On Fri, 20 Aug 2004 11:12:40 -0400 (EDT), Bruce Momjian wrote:[color=blue]
> 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.[/color]

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 pmh@edison.iopp ublishing.com
Znqr lbh ybbx

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

**Tom Lane** · Nov 23 '05, 01:44 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

"Peter Haworth" <pmh@edison.iop publishing.com> writes:[color=blue]
> ... why couldn't an explicit IS NULL test
> be allowed to use the index?[/color]

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** · Nov 23 '05, 01:45 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

In article <twig.109301269 2.59157@kelcoma ine.com>,
"Jim Wilson" <jimw@kelcomain e.com> writes:
[color=blue]
> 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.[/color]

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 YourEmailAddres sHere" to majordomo@postg resql.org)

**Jim Wilson** · Nov 23 '05, 01:45 AM

Re: How to setup default value "0000-00-00" for "date&quot ;

Harald Fuchs said:
[color=blue]
> In article <twig.109301269 2.59157@kelcoma ine.com>,
> "Jim Wilson" <jimw@kelcomain e.com> writes:
>[color=green]
> > 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.[/color]
>
> 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?[/color]

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 YourEmailAddres sHere" to majordomo@postg resql.org)

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment