The following bug has been logged online:
Bug reference: 1722
Logged by: Massimo Mollo
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.03
Operating system: win2000pro, winXphome
Description:table with a serial field don't works
Details:
I've installed
Massimo Mollo wrote:
I've installed postgres on 2 pcs, a win2000 and a winxp home.
when i create a table with a SERIAL field, the pgadmin can see and use it,
but with psql or a .net program using odbc, ole or lpgsql, the error is
RELATION *tablename* NOT FOUND.
Please supply the real query
The following bug has been logged online:
Bug reference: 1723
Logged by: Dave Chapeskie
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: FreeBSD 5.x
Description:array_cat() bug when passed empty array
Details:
I believe this bug still
Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
On Sun, 19 Jun 2005, Tom Lane wrote:
Sorry, but UTF-8 encoding doesn't work properly on Windows (yet).
Use some other database encoding.
Shouldn't we forbid its creation then?
There was serious discussion of that before the 8.0
UTF8 encoding works with the C locale assuming you don't care
about ordering of the character set, e.g. Japanese.
Has anyone with the ability to compile postgresql on windows tested the
ICU patch?
... John
---(end of broadcast)---
TIP 5:
I wrote:
Actually, I would say the bug is exec_assign_value's. There is nothing
at all wrong with a function returning one of its input values; for
example the smaller/larger functions all do that.
For that matter, you don't need a function at all:
regression=# create or replace function
Dave Chapeskie [EMAIL PROTECTED] writes:
array_cat() has a bug when passed an empty array. The
code attempts to optimise/short-circuit this case and
returns a pointer to the non-empty argument. This is
bad/wrong. Especially when used in a construct like:
foo := foo || some_array
UTF8 encoding works with the C locale assuming you don't care about
ordering of the character set, e.g. Japanese.
Has anyone with the ability to compile postgresql on windows
tested the ICU patch?
Yes.
See http://archives.postgresql.org/pgsql-hackers/2005-05/msg00662.php
//Magnus
Hello,
The PL/pgSQL FOR loop in the function consume_memory() defined below
will consume VM on each iteration until the process hits its ulimit.
The problem occurs with variables of ROWTYPE; there is no unbounded
allocation when using simple types such as integer or varchar. Before I
delve into
Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
On Sun, 19 Jun 2005, Tom Lane wrote:
Sorry, but UTF-8 encoding doesn't work properly on Windows (yet).
Use some other database encoding.
Shouldn't we forbid its creation then?
There was serious discussion of that before
Bill Rugolsky Jr. [EMAIL PROTECTED] writes:
The PL/pgSQL FOR loop in the function consume_memory() defined below
will consume VM on each iteration until the process hits its ulimit.
The problem occurs with variables of ROWTYPE; there is no unbounded
allocation when using simple types such as
On Mon, Jun 20, 2005 at 06:54:20PM -0400, Tom Lane wrote:
Bill Rugolsky Jr. [EMAIL PROTECTED] writes:
The PL/pgSQL FOR loop in the function consume_memory() defined below
will consume VM on each iteration until the process hits its ulimit.
The problem occurs with variables of ROWTYPE; there
12 matches
Mail list logo
