> I currently using postgresql V7.0.3.
> I created a database with UNICODE encoding to store chinese and japanese information.
> I have some chinese information created with MS access(excel) and export it to text
>file
> with delimiter semi-colon ";" .
> When I imiport the text file into the tabl
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Can't tell a thing from that amount of detail. What's in
> >> regression.diffs?
>
> > It appears to be the locale deal, Tom. It hits a little too familiar of
> > a chord (and pattern). If we analyze his regress
Hi,
We just find out a small bug with the getBigDecimal(int i) method in
ResultSet (postgresql 7.1 beta6)
Th symptom is :
We cannot read a decimal value with getBigDecimal() although, we can set it
We solve the problem temporary by replacing the source original method
public java.math.Big
Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Psql manual pages says:
>
> The command form \d+ is identical, but any comments
> associated with the table columns are shown as
> well.
Thank you for the response, Bruce. I was working from the HTML docs
Dear sir,
I currently using postgresql V7.0.3.
I created a database with UNICODE encoding to store
chinese and japanese information.
I have some chinese information created with MS
access(excel) and export it to text file
with delimiter semi-colon ";" .
When I imiport the text file into the
Philip ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Doc bug: libpq PQconnectPoll()
Long Description
In the online docs:
http://www.postgresql.org/users-lounge/docs/7.0/postgres/libpq-chapter.htm
The PQconnectPoll function
On Tue, 20 Mar 2001, M, Eichhorn wrote:
> 2. Should i change the LANG="en_US" to LANG="C" and send your a new regression
>
> test report?
Please. You will need to stop postmaster wipe the old database installation,
make the locale variable change, re-initdb, and start postmaster.
You see
This is fixed in the current docs:
#$ grep PQsetnonblocking *.sgml
libpq.sgml: PQsetnonblocking had been called.
libpq.sgml:address that issue, the function
PQsetnonblocking
libpq.sgml:Old applications can neglect to use
PQsetnonblocking
libpq.sgml:PQsetnonblocking to achieve a completely
non-b
Thanks, I will try that. It is in fact possible that I vacuumed the tables after
emptying them. I
couldn't imagine it had so much effect on the optimizer. But it didn't happen just
once, so I
wonder if the problem is only related to that.
And thanks for the tip for my query, I will surely
Isabelle Therrien <[EMAIL PROTECTED]> writes:
> The tables are emptied often. We don't keep these datas. So there's
> never more than 50 tuples per table. And with this query, about 3-4
> tuples are retrieved.
Well, it would appear that in the 7.1 installation, you last vacuumed
the tables just
Tom Lane wrote:
>
> Isabelle Therrien <[EMAIL PROTECTED]> writes:
> > I have a big query, reported below, that is called several times in my
> > application.
> > At least 4 active connections call it at the same time.
> > Normally, this query is executed in about 30-50 milliseconds.
> > But afte
On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote:
> Installing Postgress on a Red Hat 7.0 Server, some regression test
> failed (see below). How can i fix this failed queries?
I had similar results here at SuSE. They came from a locale bug in
glibc-2.2 . As a workaround, try to unset LANG or set it t
12 matches
Mail list logo
