Craig White wrote:
> The following bug has been logged online:
>
> Bug reference: 3032
> Logged by: Craig White
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1.5
> Operating system: Windows XP
> Description:Commit hung for days
> Details:
>
> I'm not loo
Aaron Zedonis wrote:
> The following bug has been logged online:
>
> Bug reference: 3049
> Logged by: Aaron Zedonis
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1
> Operating system: Windows
> Description:psql does not honor md5 in pg_hba.conf file
> Deta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 19, 2007 at 08:27:32PM +, Luigi Tarenga wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3033
> Logged by: Luigi Tarenga
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1.4
> Operat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 19, 2007 at 09:53:26PM +, Jessica wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3034
> Logged by: Jessica
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2
> Operating system:
"brian blakey" <[EMAIL PROTECTED]> writes:
> Shouldn't all three PQexec... functions return the same results for
> equivalent requests.
No, because they're using different underlying protocols with different
feature sets. AFAICT you do get back "INSERT 0 0" command status in
both cases, but the n
"Dmitry Koterov" <[EMAIL PROTECTED]> writes:
> [ pg_restore fails with ]
> ERROR: could not make operator class "gin__int_ops" be default for type
> pg_catalog.int4[]
> DETAIL: Operator class "_int4_ops" already is the default.
Yeah. I'd say that intarray's attempt to override the default statu
There is Solaris FAQ update. Please, look on it and let me know any
comments.
Thanks Zdenek
Rich Teer wrote:
The following bug has been logged online:
Bug reference: 2969
Logged by: Rich Teer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.2
Operating s
"Eli Green" <[EMAIL PROTECTED]> writes:
> The columns listed in constraint_column_usage in the SQL92 information
> schema are from the wrong "side" of the key.
Are you certain this is wrong? The SQL99 spec is not exactly readable on
the matter, but as best I can tell the behavior we have follows
Eli Green wrote:
> This makes it impossible to know column information for both sides of
> a foreign key.
I think the information you want is in KEY_COLUMN_USAGE.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
Patch applied. Thanks.
---
Zdenek Kotala wrote:
>
>
> There is Solaris FAQ update. Please, look on it and let me know any
> comments.
>
> Thanks Zdenek
>
>
> Rich Teer wrote:
> > The following bug has been logg
Zdenek Kotala wrote:
> There is Solaris FAQ update. Please, look on it and let me know any
> comments.
The actual answer to the question "Can I compile PostgreSQL with
Kerberos v5 support?" is "Yes, why not?". I don't think "Can I use
this weird internal private library that seems to provide a
11 matches
Mail list logo