The following bug has been logged online:
Bug reference: 4265
Logged by: Clemens Fischer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: QNX
Description:PostgreSQL fails to compile
Details:
I cannot decode any information of this bug in
The following bug has been logged online:
Bug reference: 4266
Logged by: Clemens Fischer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: QNX
Description:regress test: could not dump unrecognized node type: 925
Details:
I cannot decode th
Tom,
Thank you for the quick reply. This information was very useful.
I apologize as I was not aware of the internal limitations of the hash
aggregate implementation and the DISTINCT keyword. I also seem to have
mischaracterized this issue in an attempt to reduce the problem to one less
specific
On Thu, Jun 26, 2008 at 7:42 AM, Clemens Fischer <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4265
> Logged by: Clemens Fischer
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.3
> Operating system: QNX
> Description:
Hi,
I am using Postgres Version 8.1.4.
I installed it using UTF8 encoding. It was successfully installed. I
confirmed the same using "SHOW server_encoding" command in pgAdmin III
Query.
Problem is whenever I am trying to open the database through ODBC
connection it throws an error 'Clie
"Ashutosh Kumar S-TLS,Chennai" <[EMAIL PROTECTED]> writes:
> Problem is whenever I am trying to open the database through ODBC
> connection it throws an error 'Client encoding mismatch'.
That phrase occurs noplace in Postgres 8.1, so the error must be coming
from something on the client side. We
"Clemens Fischer" <[EMAIL PROTECTED]> writes:
> A part of the regress tests fails 'cause in src/backend/nodes/outfuncs.c the
> function _outInhRelation() is missing.
What part of which regression tests? No one else is reporting problems.
regards, tom lane
--
Sent via pg
The following bug has been logged online:
Bug reference: 4267
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: Windows XP SP3
Description:initdb fails
Details:
Hello,
initdb fails when I tried to initialize the cluster (the same
"Scott Carey" <[EMAIL PROTECTED]> writes:
> 2. The query planner does not estimate the number of returned rows
> appropriately when table inheritance / partitioning is involved, leading to
> poor choices for aggregation. Here are two explains that demonstrate this.
> The parent table has 0 rows, e
On Thu, Jun 26, 2008 at 4:39 PM, <[EMAIL PROTECTED]> wrote:
>
> creating subdirectories ... initdb: could not create directory "C:/Program
> Files/PostgreSQL": File exists
I vaguely remember hearing of some weirdness like this on systems with
a file or directory called 'C:\Program'
--
Dave Page
Hello Dave!
As I mentioned I tried "c:\progra~1\postg~1\8.3\data" path too...
The same result.
Vadim
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, Jun 26, 2008 at 6:03 PM, Vadim Karacharsky <[EMAIL PROTECTED]> wrote:
> Hello Dave!
> As I mentioned I tried "c:\progra~1\postg~1\8.3\data" path too...
> The same result.
Right - but sooner or later that may get expanded to the full path
internally anyway. Do you have a file or directory c
No, only "Program Files".
And I tried to install pgsql 8.2 (I have installed it sooner on that machine
before OS reinstall) - the same error.
May be problem in filesystem permissions?
Vadim
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
ht
"Clemens A. Fischer" <[EMAIL PROTECTED]> writes:
> here is a part of the output of the regression test:
> WARNING: could not dump unrecognized node type: 925
> DEBUG: parse tree:
> DETAIL: {QUERY :commandType 5 :querySource 0 :canSetTag
> true :utilityStmt {CREATESTMT
Oh, you've got debug_print
Tom Lane wrote:
> "Clemens A. Fischer" <[EMAIL PROTECTED]> writes:
> > here is a part of the output of the regression test:
> > WARNING: could not dump unrecognized node type: 925
> > DEBUG: parse tree:
> > DETAIL: {QUERY :commandType 5 :querySource 0 :canSetTag
> > true :utilityStmt {CREATESTMT
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Oh, you've got debug_print_parse turned on.
> But doesn't the failure indicate a potential problem that the regression
> tests are pointing out?
Only that outfuncs.c has very incomplete coverage of utility statements.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Oh, you've got debug_print_parse turned on.
>
> > But doesn't the failure indicate a potential problem that the regression
> > tests are pointing out?
>
> Only that outfuncs.c has very incomplete coverage of util
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Only that outfuncs.c has very incomplete coverage of utility statements.
> Oh, so we don't guarantee that debug_print_parse will always work.
Well, we have never bothered to make it dump everything in the
utility-statement universe, a
18 matches
Mail list logo
