O James Doherty έγραψε στις Jun 10, 2005 :
>
> The following bug has been logged online:
>
> Bug reference: 1715
> Logged by: James Doherty
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.3
> Operating system: Solaris 8 Intel
> Description:dbmirror repla
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tavis Rudd
> Sent: 06 June 2005 07:51
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] BUG #1703: dns for ftp mirrors messed up
>
>
> The following bug has been logged online:
>
> Bug reference:
Hi Tom!
Tom Lane [2005-06-11 13:13 -0400]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > This would require that support for both int and float timestamps is
> > present in the postmaster, but wouldn't require an immediate dump and
> > reload of all databases. Would that be possible in any way?
>
Whith the JDBC driver at least up to version 8.1dev-400, the
result of the
getPrecision method of ResultSetMetaData on a bigint column is 0
instead of
the expected 19.
This has been reported before but I haven't got to fixing it yet. This
is partly because I haven't seen a good explanation
The following bug has been logged online:
Bug reference: 1717
Logged by: tiejun feng
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: linux
Description:using PgOleDb-1.0.0.15 in delphi i can't edit the data
in control
Details:
i programme
Martin Pitt <[EMAIL PROTECTED]> writes:
> I just thought about how to provide a transition path if the long-term
> solution really was to get rid of integer time stamps.
I don't think anyone has suggested doing that. In fact, there's a camp
that wishes they'd become the default. I don't see that
Title: Re: [BUGS] BUG #1715: dbmirror replaces nextval, setval functions
I wouldn't say that requiring that dbmirror not break all serial
fields in the entire database is a special requirement!
The pending.so library that is compiled prior to running dbmirror would
also have to be updated,
I have no official standing, but I've spent a lot of time reading the
JDBC spec and working with various implementations, and I concur.
Precision should be the maximum number of significant digits the column
is capable of returning.
-Kevin
>>> Gilles Dubochet <[EMAIL PROTECTED]> 06/13/05 3:27
Gilles Dubochet wrote:
>>> Whith the JDBC driver at least up to version 8.1dev-400, the result
>>> of the
>>> getPrecision method of ResultSetMetaData on a bigint column is 0
>>> instead of
>>> the expected 19.
>>>
>>
>> This has been reported before but I haven't got to fixing it yet. This
>> is
Yes I'm sure. I was created right before filling it.
Thanks,
Mauro
2005/6/3, Bruno Wolff III <[EMAIL PROTECTED]>:
On Thu, Jun 02, 2005 at 20:22:07 +0100,Mauro Delfino <[EMAIL PROTECTED]
> wrote:>> I have the these two tables:> CREATE TABLE table_one> ( field1 VARCHAR(255) );>> CREATE TABLE table_t
On Mon, 13 Jun 2005 10:12:38 -0300, Mauro Delfino <[EMAIL PROTECTED]> wrote:
> > > I have the these two tables:
> > > CREATE TABLE table_one
> > > ( field1 VARCHAR(255) );
> > >
> > > CREATE TABLE table_two
> > > ( field1 VARCHAR(255) UNIQUE );
> > >
> > > SELECT DISTINCT field1 FROM table_one;
> >
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I don't have a problem with removing it as a writable option ... but
> >> I'm thinking we should leave it as a read-only GUC parameter (like
> >> the several others we have already). Otherwise we'll need to add some
> >> other metho
12 matches
Mail list logo
