Tom Lane wrote:
With the attached patch to not drop nologin roles from the flat password
file, it acts more sanely:
postgres=# create user foo nologin;
CREATE ROLE
postgres=# \c - foo
Password for user foo:
FATAL: password authentication failed for user foo
Previous connection kept
On 10/15/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Tom Lane wrote:
I notice though that the
second of the above-mentioned patches is only in HEAD, which is why
those same machines are giving scary-looking warnings in the 8.2
branch, eg wasp on 8.2:
The CVS log message for that says
Am Montag, 15. Oktober 2007 schrieb Marko Kreen:
The CVS log message for that says Allow PL/PythonU to compile on Python
2.5., but that is evidently not true. Is this just a warning cleanup,
or is there perhaps a 32 vs 64 bit issue that is being fixed there?
It's a crash fix for 64bit
sayali k wrote:
As of now, PGSQL does not support materialized views. Just wanted to confirm
the difference between the materialized view and table. Is there some
operation which can be performed only on a table and not on a materialized
view or vice-versa?
That's quite an academic
On Sat, Oct 06, 2007 at 01:53:31PM -0400, Tom Lane wrote:
I've been learning much more than I wanted to know about $SUBJECT
since putting in the src/port/chklocale.c code to try to enforce
that our database encoding matches the system locale settings.
There's an ongoing thread in -patches
On Mon, Oct 15, 2007 at 11:09:54AM +0200, Magnus Hagander wrote:
On Sat, Oct 06, 2007 at 01:53:31PM -0400, Tom Lane wrote:
I am thinking that Dave's discovery explains some previously unsolved
bug reports, such as
http://archives.postgresql.org/pgsql-bugs/2007-05/msg00260.php
If Windows
On Mon, Oct 15, 2007 at 01:26:00PM +0200, Magnus Hagander wrote:
On Mon, Oct 15, 2007 at 11:09:54AM +0200, Magnus Hagander wrote:
On Sat, Oct 06, 2007 at 01:53:31PM -0400, Tom Lane wrote:
I am thinking that Dave's discovery explains some previously unsolved
bug reports, such as
Magnus Hagander [EMAIL PROTECTED] writes:
On Sat, Oct 06, 2007 at 01:53:31PM -0400, Tom Lane wrote:
I am thinking that Dave's discovery explains some previously unsolved
bug reports, such as
http://archives.postgresql.org/pgsql-bugs/2007-05/msg00260.php
...
And given that, do we even nede to
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Sat, Oct 06, 2007 at 01:53:31PM -0400, Tom Lane wrote:
I am thinking that Dave's discovery explains some previously unsolved
bug reports, such as
http://archives.postgresql.org/pgsql-bugs/2007-05/msg00260.php
...
And given that,
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. If it doesn't need a special case, then we still lack an
explanation for the aforementioned bug report.
From what I can tell that report doesn't tell us very much - we don't
know server encoding, we don't know server locale, we
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. If it doesn't need a special case, then we still lack an
explanation for the aforementioned bug report.
From what I can tell that report doesn't tell us very much - we don't
know server encoding, we don't know
Something very strange is going on on my machine with UTF8:
postgres=# show server_encoding;
server_encoding
-
UTF8
(1 row)
postgres=# select
length(convert_from(E'\343\203\251\343\202\244\343\202\273\343\203\263','utf8'));
length
8
(1 row)
postgres=#
Gregory Stark [EMAIL PROTECTED] writes:
Something very strange is going on on my machine with UTF8:
postgres=# show server_encoding;
server_encoding
-
UTF8
(1 row)
Hm. Well this doesn't look right:
(gdb) p pg_wchar_table[PG_UTF8]
$9 = {mb2wchar_with_len = 0x8364cff
The problem was simply that wchar.c has an array indexed by server encoding
number. This puts the order back in sync. I don't haven't looked at the
surrounding code enough to know if there aren't more problems like this
lurking or if there's a way to fix it so it isn't such a pain to maintain.
Gregory Stark [EMAIL PROTECTED] writes:
Something very strange is going on on my machine with UTF8:
Argh, I missed rearranging a couple of tables in the recent patch to fix
up the encoding IDs. Will fix.
regards, tom lane
---(end of
On Fri, Oct 12, 2007 at 12:37 PM, in message
[EMAIL PROTECTED], Ron Mayer
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
With respect to you Kevin, your managers should wait. You don't
install .0 releases of any software into production without months
of
Gregory Stark [EMAIL PROTECTED] writes:
... This puts the order back in sync. I don't haven't looked at the
surrounding code enough to know if there aren't more problems like this
lurking or if there's a way to fix it so it isn't such a pain to maintain.
The real problem is I believed the
Andrew Dunstan [EMAIL PROTECTED] writes:
Looks like dict-xsyn needs some windows install help for the rules file.
Ah, I was afraid of that :-(. The bespoke rule for installing that file
looked like trouble but I forgot about it while looking at the rest of
the code.
It doesn't seem like
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Something very strange is going on on my machine with UTF8:
Argh, I missed rearranging a couple of tables in the recent patch to fix
up the encoding IDs. Will fix.
Hm, now things work correctly within the server if
Gregory Stark [EMAIL PROTECTED] writes:
Hm, now things work correctly within the server if I play with text data
generated with convert_from(). But I can't seem to send utf-8 text directly in
psql any more:
Ah, figured it out, nothing to do with the server. I didn't have the locale
set to a
Hi hackers,
Is there a technical reason we do not set the value of FOUND when
executing a dynamic statement in plpgsql?
It seems surprising that FOUND is set by SELECT, PERFORM, UPDATE,
INSERT, DELETE, etc, *except* when those statements are invoked by
EXECUTE.
I had a brief look at the code in
andy [EMAIL PROTECTED] writes:
I'd like to offer: example usage and Upgrading.
I did some hacking on your perl script to make it a bit more
bulletproof; I was worried about removing any function named 'concat'
for instance. Attached is what it looks like now.
I'm not entirely sure what to do
On Tue, 2007-10-16 at 11:24 +1000, Brendan Jurd wrote:
Is there a technical reason we do not set the value of FOUND when
executing a dynamic statement in plpgsql?
See prior discussion:
http://archives.postgresql.org/pgsql-bugs/2004-10/msg1.php
It would be easy enough to have EXECUTE
Gregory Stark [EMAIL PROTECTED] writes:
Hm, now things work correctly within the server if I play with text data
generated with convert_from(). But I can't seem to send utf-8 text directly=
in
psql any more:
Did you rebuild libpq.so? It's got the bogus table embedded in it too.
On 10/16/07, Neil Conway [EMAIL PROTECTED] wrote:
See prior discussion:
http://archives.postgresql.org/pgsql-bugs/2004-10/msg1.php
Thanks for the link. I did search the archives but unfortunately
terms like 'found' and 'execute' generate a lot of unwanted matches =)
It would be
On Mon, 15 Oct 2007, Tom Lane wrote:
andy [EMAIL PROTECTED] writes:
I'd like to offer: example usage and Upgrading.
I did some hacking on your perl script to make it a bit more
bulletproof; I was worried about removing any function named 'concat'
for instance. Attached is what it looks like
Hi,
V3 protocol seems to be slower than V2 if we don't use prepared statement
together. I measured performance of protocols on 8.3beta using pgbench -S
with modification to use PQsendQueryParams and PQsendQueryPrepared
instead of PQsendQuery. (I'll send the patch to -patches shortly.)
[V2]
Hi hackers,
I recently ran afoul of the following error message:
ERROR: type of varname does not match that when preparing the plan
IMO the message isn't quite in English and doesn't explain the problem
very well. I'd like to change it to something more like
ERROR: the type of varname does
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
[V2] PQsendQuery (V2; original)
[V3] PQsendQueryParams (V3)
[V3P] PQsendQueryPrepared (V3 with prepared statements)
V3 was 12% slower than V2, and V3P was 40% faster than V2.
Those aren't really comparable, because the functionality is
Brendan Jurd [EMAIL PROTECTED] writes:
I recently ran afoul of the following error message:
ERROR: type of varname does not match that when preparing the plan
IMO the message isn't quite in English and doesn't explain the problem
very well.
The English is fine. What I want to know about is
On 10/16/07, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I recently ran afoul of the following error message:
ERROR: type of varname does not match that when preparing the plan
IMO the message isn't quite in English and doesn't explain the problem
very well.
2007/10/16, Neil Conway [EMAIL PROTECTED]:
On Tue, 2007-10-16 at 11:24 +1000, Brendan Jurd wrote:
Is there a technical reason we do not set the value of FOUND when
executing a dynamic statement in plpgsql?
See prior discussion:
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
[V2] PQsendQuery (V2; original)
[V3] PQsendQueryParams (V3)
[V3P] PQsendQueryPrepared (V3 with prepared statements)
V3 was 12% slower than V2, and V3P was 40% faster than V2.
Those aren't really
2007/10/16, Brendan Jurd [EMAIL PROTECTED]:
On 10/16/07, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I recently ran afoul of the following error message:
ERROR: type of varname does not match that when preparing the plan
IMO the message isn't quite in
On 10/16/07, Pavel Stehule [EMAIL PROTECTED] wrote:
please, read:
http://www.pgsql.cz/index.php/Automatic_execution_plan_caching_in_PL/pgSQL
Thanks Pavel,
I actually came across that wiki article via Google when I was first
trying to learn more about the message. But, I'm not asking for help
35 matches
Mail list logo
