Skip site navigation (1) Skip section navigation (2)

Re: help: now() + N is now failing!

From: Dmitry Tkach <dmitry(at)openratings(dot)com>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: help: now() + N is now failing!
Date: 2003-07-29 21:14:18
Message-ID: 3F26E3AA.9040409@openratings.com (view raw or flat)
Thread:
Lists: pgsql-novice
Stephan Szabo wrote:

>On Tue, 29 Jul 2003, Dmitry Tkach wrote:
>
>  
>
>>Stephan Szabo wrote:
>>
>>    
>>
>>>The first doesn't, date_pli('foo', 2) that's just text->date
>>>
>>>      
>>>
>>But you can't cast 'foo' into date, can you? I mean, there is a cast,
>>but it will fail, right.
>>And if you used a valid date textual representation, then, I don't see
>>any reason why
>>date_pli ('29/07/03', 2) should not work
>>
>>And, as a matter of fact, it *does*, unless you add '::text' to it (in
>>7.3 - 7.2 is still OK with it).
>>    
>>
>
>That's because it's actually unknown, not text. 
>
I know :-)

> But, should
>date_pli(textcolumn, 2) work if and only if all the values of the column
>happen to be date like?  That's pretty brittle and even more so since
>there's no obvious conversion being done.
>
Well... This sounds like a different topic alltogether to me - 
generally, the question is should it be possible at all to *cast* 
(whether explicitly or implicitly) type A into type B when the 
conversion is only possible for a small subset of possible values of type A.
I mean, something like parse_date(text) is fine, but textcolumn::date 
is, indeed, questionable.

I don't really know the answer to this question (but I do lean toward 
the position, that conversions like this should not be possible as casts 
per se)...

But my point is that if you can (unambigously) cast a value into a 
target type, then in the tradition of commonly used programming 
languages, it would be reasonable to expect it to be possible to invoke 
a function that expects that type as an argument with the original value 
as a parameter, and have it get casted implicitly to match the function 
declaration.

My understanding is that this was, pretty much, the whole idea behind 
the 'polymorphism', and function overloading in general -
you define an 'operator +'  for your basic types, and expect it to work 
on anything you send in... Having to define it separately for every 
possible combination of types (and having the code do the exact same 
thing in most of the cases) kinda defeats the purpose, doesn't it?

>
>You use an example of C++ and inheritance, but Timestamp is not a subclass
>of Date or vice versa. 
>
I knew, you'd say that :-)
That example was meant as just an analogy.
The timestamp being or not being a subclass of date is an implementation 
detail. From the user's standpoint, for all intents and purposes, it 
*is* - timestamp is a date, with some additional information...

>Effectively we have a Date(Timestamp) explicit
>constructor. 
>
Ok, that beats your previous point, right? :-)
I mean, in C++ it is enough to have a constructor like that defined, 
even if timestamp is not not a subclass of date, it can still be 
implicitly converted, as long as the constructor is defined.... :-)

>You can't call a date expecting function with a timestamp
>because the conversion is not legal unless explicitly made.  And C++ at
>least does allow multiple conversions, just not multiple user-defined
>conversions (for example int->double, double->classtype is allowed).
>
>  
>
Yep. You are right, I forgot about that...
Well.. perhaps, postgres should allow that too eventually then :-)
But, just allowing single-step conversions for now would be agood 
starting point anyway... :-)

Dima



In response to

Responses

pgsql-novice by date

Next:From: Tom LaneDate: 2003-07-29 21:25:32
Subject: Re: help: now() + N is now failing!
Previous:From: Stephan SzaboDate: 2003-07-29 20:59:06
Subject: Re: help: now() + N is now failing!

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group