Обсуждение: Timestamp precision

Поиск
Список
Период
Сортировка

Timestamp precision

От
Daniel Bruce Lynes
Дата:
We were having difficulty comparing timestamps in postgreSQL, using the jdbc3
driver.  However, after reviewing the jdbc driver code, I found that the
precision problem I encountered is deliberately coded into the driver.

Why is it that the jdbc driver truncates the fractional part of the seconds to
3 decimal places?

Thanks for any direction you might be able to offer in this respect.

SQL Sessions and the DROP DATABASE command

От
"Carl Olivier"
Дата:

Greetings.

I need to be able to call the DROP DATABASE database command via JDBC.

Unfortunately I need to kill off any active connections to the specified database before the DROP DATABASE command will work.

Is there anyway from within a JDBC connection to say the template1 database as the superuser on a POSTGRESQL server to:

1.  Determine what connections are open and active to a specified database
2.  Kill ALL these sessions.

Thank you in advance,

Carl Olivier

Re: SQL Sessions and the DROP DATABASE command

От
Dave Cramer
Дата:
Carl,

This is not possible through the jdbc interface.

Dave
On Thu, 2003-03-06 at 04:25, Carl Olivier wrote:
> Greetings.
>
> I need to be able to call the DROP DATABASE database command via JDBC.
>
> Unfortunately I need to kill off any active connections to the
> specified database before the DROP DATABASE command will work.
>
> Is there anyway from within a JDBC connection to say the template1
> database as the superuser on a POSTGRESQL server to:
>
> 1.  Determine what connections are open and active to a specified
> database
> 2.  Kill ALL these sessions.
>
> Thank you in advance,
>
> Carl Olivier
--
Dave Cramer <Dave@micro-automation.net>


Re: SQL Sessions and the DROP DATABASE command

От
"Carl Olivier"
Дата:
Hey.

Thanks for the reply, although not what I wanted to hear ;)

damn!

so you mean that I cannot do this except on the actual machine or via a
shell script with sufficient permissions?!?!

Carl

-----Original Message-----
From: Dave Cramer [mailto:Dave@micro-automation.net]
Sent: 06 March 2003 03:34 PM
To: carl@zero-one.co.za
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] SQL Sessions and the DROP DATABASE command


Carl,

This is not possible through the jdbc interface.

Dave
On Thu, 2003-03-06 at 04:25, Carl Olivier wrote:
> Greetings.
>
> I need to be able to call the DROP DATABASE database command via JDBC.
>
> Unfortunately I need to kill off any active connections to the
> specified database before the DROP DATABASE command will work.
>
> Is there anyway from within a JDBC connection to say the template1
> database as the superuser on a POSTGRESQL server to:
>
> 1.  Determine what connections are open and active to a specified
> database
> 2.  Kill ALL these sessions.
>
> Thank you in advance,
>
> Carl Olivier
--
Dave Cramer <Dave@micro-automation.net>


Re: SQL Sessions and the DROP DATABASE command

От
Dave Cramer
Дата:
Well, you could do it within java, but not through the jdbc interface.

ie execute a c/shell/whatever program which does it.

Dave

On Thu, 2003-03-06 at 08:39, Carl Olivier wrote:
> Hey.
>
> Thanks for the reply, although not what I wanted to hear ;)
>
> damn!
>
> so you mean that I cannot do this except on the actual machine or via a
> shell script with sufficient permissions?!?!
>
> Carl
>
> -----Original Message-----
> From: Dave Cramer [mailto:Dave@micro-automation.net]
> Sent: 06 March 2003 03:34 PM
> To: carl@zero-one.co.za
> Cc: pgsql-jdbc@postgresql.org
> Subject: Re: [JDBC] SQL Sessions and the DROP DATABASE command
>
>
> Carl,
>
> This is not possible through the jdbc interface.
>
> Dave
> On Thu, 2003-03-06 at 04:25, Carl Olivier wrote:
> > Greetings.
> >
> > I need to be able to call the DROP DATABASE database command via JDBC.
> >
> > Unfortunately I need to kill off any active connections to the
> > specified database before the DROP DATABASE command will work.
> >
> > Is there anyway from within a JDBC connection to say the template1
> > database as the superuser on a POSTGRESQL server to:
> >
> > 1.  Determine what connections are open and active to a specified
> > database
> > 2.  Kill ALL these sessions.
> >
> > Thank you in advance,
> >
> > Carl Olivier
> --
> Dave Cramer <Dave@micro-automation.net>
--
Dave Cramer <Dave@micro-automation.net>


Re: Timestamp precision

От
Barry Lind
Дата:
Daniel,

What code are you refering to exactly?  I don't see this, and there is a
test in the jdbc test suite that tests time out to 6 decimal places.

thanks,
--Barry


Daniel Bruce Lynes wrote:
> We were having difficulty comparing timestamps in postgreSQL, using the jdbc3
> driver.  However, after reviewing the jdbc driver code, I found that the
> precision problem I encountered is deliberately coded into the driver.
>
> Why is it that the jdbc driver truncates the fractional part of the seconds to
> 3 decimal places?
>
> Thanks for any direction you might be able to offer in this respect.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>




Re: Timestamp precision

От
Daniel Bruce Lynes
Дата:
On Thursday 06 March 2003 09:23, Barry Lind wrote:

> What code are you refering to exactly?  I don't see this, and there is a
> test in the jdbc test suite that tests time out to 6 decimal places.

Hrm.  I downloaded the 7.3.2 code, and the problem doesn't exist in that code.
I'll have to take a look at the code I've got at the office.  I think it was
7.2.3(?).

I downloaded it around December I think.  I'll check the version number
tomorrow.

Re: Timestamp precision

От
Daniel Bruce Lynes
Дата:
On Thursday 06 March 2003 19:22, Daniel Bruce Lynes wrote:

> On Thursday 06 March 2003 09:23, Barry Lind wrote:
> > What code are you refering to exactly?  I don't see this, and there is a
> > test in the jdbc test suite that tests time out to 6 decimal places.
>
> Hrm.  I downloaded the 7.3.2 code, and the problem doesn't exist in that
> code. I'll have to take a look at the code I've got at the office.  I think
> it was 7.2.3(?).
>
> I downloaded it around December I think.  I'll check the version number
> tomorrow.

It was 7.3, and the code was in AbstractJdbc1ResultSet.java.