> > ... then trailing zeros are hacked out,
> > two digits at a time.
>
> I was wondering why it seemed to always want to produce an even number
> of fractional digits. Why are you doing it 2 at a time and not 1?
> I should think timestamp(1) would produce 1 fractional digit, not
> two digits o
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Not sure where pg_dump and other utilities gin up the SQL9x type names,
> but we should fix things during beta to be consistant.
I believe pg_dump and psql are already okay now that I fixed
format_type. Not sure if there are dependencies in other uti
> > ... then trailing zeros are hacked out,
> > two digits at a time.
> I was wondering why it seemed to always want to produce an even number
> of fractional digits. Why are you doing it 2 at a time and not 1?
> I should think timestamp(1) would produce 1 fractional digit, not
> two digits of wh
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> ... then trailing zeros are hacked out,
> two digits at a time.
I was wondering why it seemed to always want to produce an even number
of fractional digits. Why are you doing it 2 at a time and not 1?
I should think timestamp(1) would produce 1 fract
> Can you explain more how this functionality has changed? I know that in
> the JDBC driver fractional seconds are assumed to be two decimal places.
> If this is no longer true, I need to understand the new symantics so
> that the JDBC parsing routines can be changed. Other interfaces may
> ha
Thanks Thomas...at least there will be a way to specify more than 2. we are looking
forward to this release...
L.
On Thu, 4 Oct 2001, Thomas Lockhart wrote:
> Laurette Cisneros wrote:
> >
> > Could I get some more specific information on how this is fixed. Keep in mind
>that using tochar() i
Thomas,
Can you explain more how this functionality has changed? I know that in
the JDBC driver fractional seconds are assumed to be two decimal places.
If this is no longer true, I need to understand the new symantics so
that the JDBC parsing routines can be changed. Other interfaces may
Laurette Cisneros wrote:
>
> Could I get some more specific information on how this is fixed. Keep in mind that
>using tochar() is not an option for us in that we ned to use COPY to/from the client.
I'm finishing up implementing SQL99-style precision features in
timestamp et al, so there will
Hi Thomas,
Could I get some more specific information on how this is fixed. Keep in mind that
using tochar() is not an option for us in that we ned to use COPY to/from the client.
Thanks,
L.
On Thu, 4 Oct 2001, Thomas Lockhart wrote:
> > Problem: the external representation of time and time
This is very good news. Thanks to all for the response.
L.
On Thu, 4 Oct 2001, Karel Zak wrote:
> On Wed, Oct 03, 2001 at 05:02:59PM -0700, Laurette Cisneros wrote:
>
> > A work around for display might be to use to_char().
>
> In 7.2 is possible use millisecond / microsecond format:
>
> # sel
On Wed, Oct 03, 2001 at 05:02:59PM -0700, Laurette Cisneros wrote:
> A work around for display might be to use to_char().
In 7.2 is possible use millisecond / microsecond format:
# select to_char(now()+'2s 324 ms'::interval, 'HH:MM:SS MS');
to_char
--
10:10:59 324
(1 row)
# se
> Problem: the external representation of time and timestamp are
> less precise than the internal representation.
Fixed (as of yesterday) in the upcoming release.
- Thomas
---(end of broadcast)---
TIP 2: you can ge
12 matches
Mail list logo
