Re: Empty date

Hi Guys

Thanks again for your responses.
You were all RIGHT .. again!
a null column was returned, which bombed out the stored procedure.
This was resolved using ur advice.

Kind Regards,
Shaun Clements
B.Com (Hons) IST
Software Developer
Relyant Group IT
Business ConneXion (Pty) Ltd
As service provider for: Relyant

Office: +27 (0)31 3674722
Mobile: +27 (0)84 6166777
Fax: +27 (0)31 3055289
Email: Shaun(dot)Clements(at)bcx(dot)co(dot)za
<mailto:Shaun(dot)Clements(at)bcx(dot)co(dot)za>
Web Site: www.bcx.co.za <http://www.bcx.co.za/>

" Obstacles are what we see when we take our eyes off the goal "

Hi ,

Thanks your previous help. I have a new question : how to store empty value to date field ? ( I always get error message, in vain use any format )
In my client be empty value for date fields (' . . ') , and I would like to use NULL values and empty values also.

Thanks : Zoltan

Szmutku Zoltán wrote:
> Hi ,
>
> Thanks your previous help. I have a new question : how to store
> empty value to date field ? ( I always get error message, in vain use
> any format ) In my client be empty value for date fields (' . .
> ') , and I would like to use NULL values and empty values also.

How can " " be a valid date?

You might want to reconsider your design.
--
Richard Huxton
Archonet Ltd

> In my client be empty value for date fields (' . . ') , and I would
> like to use NULL values and empty values also.

What is your reason to put empty value ('') as alternative of null value?

I have a ODBC client which uses empty dates in its native data engine.
Unfortunately, empty data causes error if trying to store it.
This is serious Postgres limitation.
For a partial fix ODBC driver or postgres should convert empty dates to
NULLs automatically. This is better that producing error.

>> How can " " be a valid date? <<
>> You might want to reconsider your design. <<

Using your logic, I can ask: How can be 0 valid number ? If there is not
empty dates, number 0 cannot be also legal.

Empty data is a date which is less that all other dates. It can be used in
comparisons.
In contract, NULL date means that date is not entered.

Andrus Moor

"Richard Huxton" <dev(at)archonet(dot)com> wrote in message
news:424A7831(dot)6040805(at)archonet(dot)com(dot)(dot)(dot)
> Szmutku Zoltn wrote:
>> Hi ,
>>
>> Thanks your previous help. I have a new question : how to store
>> empty value to date field ? ( I always get error message, in vain use
>> any format ) In my client be empty value for date fields (' . .
>> ') , and I would like to use NULL values and empty values also.
>
> How can " " be a valid date?
>
> You might want to reconsider your design.
> --
> Richard Huxton
> Archonet Ltd
>
> ---------------------------(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
>

On Thu, Mar 31, 2005 at 09:43:27AM +0300, Andrus wrote:

> Empty data is a date which is less that all other dates.

Why would that be ? "<Empty> of type <unknown>" cannot be less
than (nor more than nor equal to) "<not empty> of type <date>".
If you want to express the valid idea of "<less-than-anything>
of type <date>" you are better off using a logical construct
tailored for that purpose. It may help to use "<4734-01-01 BC> of
type <date>" or some such. However the best would be to use
"-infinity". See the docs.

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

On Sun, Apr 03, 2005 at 11:06:22 +0200,
Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> wrote:
> On Thu, Mar 31, 2005 at 09:43:27AM +0300, Andrus wrote:
>
> > Empty data is a date which is less that all other dates.
>
> Why would that be ? "<Empty> of type <unknown>" cannot be less
> than (nor more than nor equal to) "<not empty> of type <date>".
> If you want to express the valid idea of "<less-than-anything>
> of type <date>" you are better off using a logical construct
> tailored for that purpose. It may help to use "<4734-01-01 BC> of
> type <date>" or some such. However the best would be to use
> "-infinity". See the docs.

+/- infinity are only available as timestamps, not dates.

> > type <date>" or some such. However the best would be to use
> > "-infinity".
>
> +/- infinity are only available as timestamps, not dates.
Hm, any particular reason why ? Apart from no one having
gotten around to doing it...

Strange enough, on 7.4.6 I am unsure as to how to interpret
the output of:

select ('2000-10-10'::date < 'infinity'::timestamp::date);

?column?
----------

(1 row)

Further testing shows it seems to be of type boolean. Is it
NULL ? Coalesce did not help.

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

On Sun, Apr 03, 2005 at 15:46:18 +0200,
Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> wrote:
> > > type <date>" or some such. However the best would be to use
> > > "-infinity".
> >
> > +/- infinity are only available as timestamps, not dates.
> Hm, any particular reason why ? Apart from no one having
> gotten around to doing it...

I think that is it. I seem to remember a discussion of that about 2 or 3
years ago, but nothing came of it.

> Strange enough, on 7.4.6 I am unsure as to how to interpret
> the output of:
>
> select ('2000-10-10'::date < 'infinity'::timestamp::date);
>
> ?column?
> ----------
>
> (1 row)
>
> Further testing shows it seems to be of type boolean. Is it
> NULL ? Coalesce did not help.

area=> select 'infinity'::timestamp::date is null;
?column?
----------
t
(1 row)

> area=> select 'infinity'::timestamp::date is null;
> ?column?
> ----------
> t
> (1 row)
Ah, thanks.

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

on 3/30/05 11:43 PM, noeetasoftspam(at)online(dot)ee purportedly said:

> I have a ODBC client which uses empty dates in its native data engine.
> Unfortunately, empty data causes error if trying to store it.
> This is serious Postgres limitation.
> For a partial fix ODBC driver or postgres should convert empty dates to
> NULLs automatically. This is better that producing error.
>
>>> How can " " be a valid date? <<
>>> You might want to reconsider your design. <<
>
> Using your logic, I can ask: How can be 0 valid number ? If there is not
> empty dates, number 0 cannot be also legal.

It's mathematics 101. 0 *is* a valid integer. The SQL standard defines that
any field must either have a valid value, or be NULL, which means "no
value"--and not any idea of "not entered" because you can very easily enter
a NULL value into any field. Therefore logic would dictate that a field
either has a value, or it doesn't, in SQL, this means it has a (valid) value
or is NULL.

> Empty data is a date which is less that all other dates. It can be used in
> comparisons.
> In contract, NULL date means that date is not entered.

There is no such thing as an "empty date". Just like there is no such thing
as an empty boolean, or an empty number. The mistaken notion of "empty" date
seems to proceed from the concept of an "empty string", which is in no way
applicable to any other data type. A string is an array of bytes of X length
where X is an integer. So an "empty" string is just an array of bytes of
zero length.

Looking at dates again, when is 0 date? I suppose Postgres could include the
current computations for the occurrence of the "big bang" but the storage
requirements for such an number, simply to store a current date, would be
highly impractical.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> writes:
>> area=> select 'infinity'::timestamp::date is null;
>> ?column?
>> ----------
>> t
>> (1 row)
> Ah, thanks.

I think this is a bug BTW. If we can't convert the value correctly,
we ought to raise an error not return NULL.

regards, tom lane

The format_type function is great, except for the way it formats varchars,
it always returns Character Varying or whatever, it would be nice if it
had a option to return a short version of
these names. i.e.

format_type(a.atttypid, a.atttypmod,true) would return all short names

format_type(a.atttypid, a.atttypmod,false) would return full names

I don't know of any other system that shows varchars in this way, they
should just be formated as varchar(50).

If there is another way to do this without messy case statements please
let me know.

Thanks,

Tony

Tony Caduto <tony_caduto(at)amsoftwaredesign(dot)com> writes:
> The format_type function is great, except for the way it formats varchars,
> it always returns Character Varying or whatever,
> ...
> I don't know of any other system that shows varchars in this way, they
> should just be formated as varchar(50).

Hmm ... AFAICS, "character varying(n)" and "varchar(n)" are equally
valid spellings according to the SQL spec.

I'd personally prefer the shorter spelling too, but I can't see any
particularly strong argument for changing it.

regards, tom lane

Would it not be possible to add another param to the function like I mentioned
and keep everyone happy? Users coming from MS SQL server look puzzled when
they see the huge Character Varying(n) in a admin tool.

I have not programmed in C since 1993, but I know in pascal you can have a
parameter for a function be set as a const, that way it would remain
compatible with the current function, then some logic could be added to make
the long names be short? or even a overloaded function would be ok.

I have got around this by using a case statment but it would be so nice if I
could just call that function and have the results look like what users see
in tools such as MS SQL servers enterprise manager.

Thanks,

Tony

On Sunday 03 April 2005 20:49 pm, Tom Lane wrote:
> Tony Caduto <tony_caduto(at)amsoftwaredesign(dot)com> writes:
> > The format_type function is great, except for the way it formats
> > varchars, it always returns Character Varying or whatever,
> > ...
> > I don't know of any other system that shows varchars in this way, they
> > should just be formated as varchar(50).
>
> Hmm ... AFAICS, "character varying(n)" and "varchar(n)" are equally
> valid spellings according to the SQL spec.
>
> I'd personally prefer the shorter spelling too, but I can't see any
> particularly strong argument for changing it.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

On Sun, Apr 03, 2005 at 08:54:12PM -0400, Tom Lane wrote:
> >> area=> select 'infinity'::timestamp::date is null;
> >> ?column?
> >> ----------
> >> t
> >> (1 row)
> > Ah, thanks.
>
> I think this is a bug BTW. If we can't convert the value correctly,
> we ought to raise an error not return NULL.
Which is *why* I wasn't sure how to interpret it.

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

Tony Caduto wrote:
> Would it not be possible to add another param to the function like I mentioned
> and keep everyone happy? Users coming from MS SQL server look puzzled when
> they see the huge Character Varying(n) in a admin tool.
>
> I have not programmed in C since 1993, but I know in pascal you can have a
> parameter for a function be set as a const, that way it would remain
> compatible with the current function, then some logic could be added to make
> the long names be short? or even a overloaded function would be ok.
>
> I have got around this by using a case statment but it would be so nice if I
> could just call that function and have the results look like what users see
> in tools such as MS SQL servers enterprise manager.

We don't have function overloading like that in C, so we would need a
new function and have to keep the old one around too.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073