Magnus Hagander wrote:
2009/10/13 Tom Lane t...@sss.pgh.pa.us:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Magnus Hagander wrote:
Actually, I found a note that said it's recommended to never increase
it about 65535 - so perhaps we should put our limit at that instead od
t...@sss.pgh.pa.us (Tom Lane) writes:
Christian DUPONT christian.dup...@cegelec.com writes:
I use slony 1 v 1.2.14.
After an unexpected stop, several tables remained locked :
Is it possible that the locks are being held by a prepared transaction?
Next time it happens, look into the
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
A small wish in case we go with this: The constant should be named
something like PG_...; otherwise it looks like we are defining or
overriding an official symbol from the GSS API.
I'd be inclined to just s/2000/32767/ and not bother
Hi guys,
I'm not sure what the source of this bug is, as I'm getting a
discrepancy between 8.1 on Linux vs. 8.4 on Windows, using the latest
JDBC driver type 4.
The issue is this, I have a nullable integer column in one of my
tables. When I'm updating the column in 8.4 Windows with value 0, it
The following bug has been logged online:
Bug reference: 5114
Logged by:
Email address: flamindrag...@gmail.com
PostgreSQL version: any
Operating system: Win XP Pro SP2
Description:database initialization
Details:
Hey I keep getting the failed to run initdb: 1
Sean Hsien umph...@gmail.com wrote:
using the latest JDBC driver type 4.
I have a nullable integer column in one of my tables. When I'm
updating the column in 8.4 Windows with value 0, it stays as null,
but on the Linux 8.1 it will try to update it with the value 0.
Could you post a
The following bug has been logged online:
Bug reference: 5115
Logged by: Vladimir Kokovic
Email address: vladimir.koko...@a-asoft.com
PostgreSQL version: PostgreSQL 8.4.
Operating system: Linux vlD-kuci 2.6.28-15-generic #52-Ubuntu SMP Wed Sep
9 10:49:34 UTC 2009 i686
Vladimir Kokovic vladimir.koko...@a-asoft.com wrote:
For ALTER TABLE ADD CONSTRAINT documentation says:
ADD table_constraint
This form adds a new constraint to a table using the same syntax
as CREATE TABLE.
Which is specified as UNIQUE ( column_name [, ... ] )
But if expression
Vladimir Kokovic vladimir.koko...@a-asoft.com writes:
For ALTER TABLE ADD CONSTRAINT documentation says:
ADD table_constraint
This form adds a new constraint to a table using the same syntax as
CREATE TABLE.
But if expression is used in the constraint definition
server says:
# ALTER
Vladimir Kokovic wrote:
For ALTER TABLE ADD CONSTRAINT documentation says:
ADD table_constraint
This form adds a new constraint to a table using the same syntax as
CREATE TABLE.
But if expression is used in the constraint definition
server says:
# ALTER TABLE
=?UTF-8?B?VmxhZGltaXIgS29rb3ZpxIc=?= vladimir.koko...@a-asoft.com writes:
Real question is Why we need two syntaxes for the same thing ?
Because the SQL standard says so: UNIQUE-constraint syntax is limited
to simple column names. We can't just extend that because it would
break the
I'll rename it to PG_MAX_AUTH_TOKEN_LENGTH, unless someone has a better
suggestion.
If we are not changing this for all authentication schemes, then the name
should probably reflect that this is for GSS and SSPI only (not even KRB5).
--Ian
--
Sent via pgsql-bugs mailing list
Turner, Ian ian.tur...@deshaw.com writes:
I'll rename it to PG_MAX_AUTH_TOKEN_LENGTH, unless someone has a better
suggestion.
If we are not changing this for all authentication schemes, then the name
should probably reflect that this is for GSS and SSPI only (not even KRB5).
Then we'd have
The original naming complaint reflected a concern that
the symbol looked like it was supplied by the system headers, rather
than being of Postgres origin. Heikki's suggestion deals with that,
and I think it's fine as-is.
OK, fine with me.
--Ian
--
Sent via pgsql-bugs mailing list
The following bug has been logged online:
Bug reference: 5116
Logged by: Nikolai Wendorf
Email address: nikol...@embarqmail.com
PostgreSQL version: 8.4.1
Operating system: Solaris 9
Description:could not determine encoding for locale
Details:
30psql
psql (8.4.1)
Nikolai Wendorf nikol...@embarqmail.com writes:
Operating system: Solaris 9
Description:could not determine encoding for locale
WARNING: could not determine encoding for locale en_US.ISO8859-1: codeset
is 646
Well, that's truly stupid :-(. The only plausible referent for 646
that
16 matches
Mail list logo