Thread: Interval Precision

Interval Precision

From
Jake Stride
Date:
Hi,

I'm trying to force the precision on an interval so that I can store
hours and minutes and then when I do a select just see the hours and
minutes. i.e.:

01:00 instead of 01:00:00

is the possible as no matter what I set the precision to I always get
the extra seconds. Is this possible?

Thanks

Jake

Re: Interval Precision

From
Bruno Wolff III
Date:
On Fri, Apr 08, 2005 at 19:52:00 +0100,
  Jake Stride <nsuk@users.sourceforge.net> wrote:
> Hi,
>
> I'm trying to force the precision on an interval so that I can store
> hours and minutes and then when I do a select just see the hours and
> minutes. i.e.:
>
> 01:00 instead of 01:00:00
>
> is the possible as no matter what I set the precision to I always get
> the extra seconds. Is this possible?

You can use the to_char function to format the output.

Re: Interval Precision

From
Jake Stride
Date:
Bruno Wolff III wrote:

>On Fri, Apr 08, 2005 at 19:52:00 +0100,
>  Jake Stride <nsuk@users.sourceforge.net> wrote:
>
>
>>Hi,
>>
>>I'm trying to force the precision on an interval so that I can store
>>hours and minutes and then when I do a select just see the hours and
>>minutes. i.e.:
>>
>>01:00 instead of 01:00:00
>>
>>is the possible as no matter what I set the precision to I always get
>>the extra seconds. Is this possible?
>>
>>
>
>You can use the to_char function to format the output.
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>               http://archives.postgresql.org
>
>
That works, thanks but what about this from the manual:

' Warning: |to_char|(interval, text) is deprecated and should not be
used in newly-written code. It will be removed in the next version.'

Thanks

Jake

Re: Interval Precision

From
Bruno Wolff III
Date:
On Fri, Apr 08, 2005 at 20:17:45 +0100,
  Jake Stride <nsuk@users.sourceforge.net> wrote:
>
> ' Warning: |to_char|(interval, text) is deprecated and should not be
> used in newly-written code. It will be removed in the next version.'

That isn't cast in stone at this point. The problem is that there are
some significant problems with to_char and interval now and some people
feel that getting rid of it is better than providing a broken feature.
If someone comes up with an acceptable spec and implements it for 8.1,
it won't go away.

If it does go away, the fallback is to use EXTRACT and some math.

Re: Interval Precision

From
Steve Crawford
Date:
On Friday 08 April 2005 12:17 pm, Jake Stride wrote:
> ...but what about this from the manual:
>
> ' Warning: |to_char|(interval, text) is deprecated and should not
> be used in newly-written code. It will be removed in the next
> version.'

Check the archive of the HACKERS list for messages with the subject
"Bug 1500".

I don't see that any absolute decision has been reached but the
majority opinion seems to be to fix the problems with interval
formatting and possibly also extend/improve it rather than to kill it
off.

Cheers,
Steve


Re: Interval Precision

From
Tom Lane
Date:
Steve Crawford <scrawford@pinpointresearch.com> writes:
> Check the archive of the HACKERS list for messages with the subject
> "Bug 1500".

> I don't see that any absolute decision has been reached but the
> majority opinion seems to be to fix the problems with interval
> formatting and possibly also extend/improve it rather than to kill it
> off.

I don't think there's any way that we'll remove it until a better
implementation is available.  Karel was essentially arguing "if you
take it away then someone will be motivated to write the better
version", but we don't generally work that way ...

The basic issue is that it's sharing code with to_char(timestamp)
and therefore accepts a whole bunch of format codes that don't really
make sense for intervals; and at the same time is lacking some that
do make sense.  So when it does get fixed you might have some issues
with format codes going away ... but the ones that are actually useful
with intervals, like HH and MI, presumably will still be there.

            regards, tom lane