On Oct 1, 2009, at 4:18 PM, Robert Haas wrote:
On Thu, Oct 1, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The elephant in the room here is that if the relation is a million
pages of which 1-100,000 and 1,000,000 are in use, no amount of bias
new version under:
http://zlew.org/postgresql_static_check/scan-build-2009-10-03-1/
What's strange, is the increase of 48.2 percent in reports, that
happened about two weeks before (weekend before the previous one).
enjoy.
--
Sent via pgsql-hackers mailing list
I would like to propose a change in the way privilege checking is done
with inheritance hierarchies. Currently, selecting from a table that
has children requires explicit privileges on all the children. This is
inconsistent with all other commands, which treat children as implicitly
part of the
On Sat, 2009-10-03 at 00:42 -0400, Tom Lane wrote:
As far as I can tell, PLyObject_ToDatum is invoking PLyUnicode_Str and
then PyString_AsString, and what it gets back from the latter is
(in C string notation) \200\0. Possibly what this means is that
python thinks that that is the correct
Bruce Momjian wrote:
Tom Lane wrote:
That said, it would still be good to have something actually *useful*
in contrib. A bit more than just comparing userid and password.
Perhaps at least being able to set the min length, and the requirement
on having 1 character class?
+1. There's
--On 1. Oktober 2009 17:22:06 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
- The patch as is has still some locking problems (AlterRoleSet()
has a XXX about that): I've managed to create dead entries for a
role or a database in pg_db_role_setting while altering and dropping
a
Peter Eisentraut pete...@gmx.net writes:
So let's get rid of that. Selecting (or in general, operating) on a
table with children only checks the privileges on that table, not the
children.
+1
We could use a GUC variable to ease the transition, perhaps like
sql_inheritance = no |
Robert Haas robertmh...@gmail.com wrote:
let's let the default, global default ACL contain the hard-wired
privileges, instead of making them hardwired.
+1
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Peter Eisentraut pete...@gmx.net writes:
On Sat, 2009-10-03 at 00:42 -0400, Tom Lane wrote:
As far as I can tell, PLyObject_ToDatum is invoking PLyUnicode_Str and
then PyString_AsString, and what it gets back from the latter is
(in C string notation) \200\0. Possibly what this means is that
On Sat, 2009-10-03 at 11:21 -0400, Tom Lane wrote:
Well, there are assorted Windows code pages in which 0x80 *is* supposed
to map to the Euro sign. I suspect some confusion somewhere in
Solaris-land about the definition of LATIN2. But the main point here
is that what is coming out, on my
Peter Eisentraut pete...@gmx.net writes:
On Sat, 2009-10-03 at 11:21 -0400, Tom Lane wrote:
Where exactly are you expecting the latter string to get
substituted in?
The way I understand it, the \u comes from psql, mbprint.c. So this
may depend on exactly what locale psql, as run by
On Sat, 2009-10-03 at 12:20 -0400, Tom Lane wrote:
I am inclined to think that we should add another expected-file
showing the single-byte \200 result. What that might get displayed
as on the local system isn't really our concern.
OK, the reason I couldn't reproduce this for the life of me is
Peter Eisentraut pete...@gmx.net writes:
OK, the reason I couldn't reproduce this for the life of me is that I
had PGCLIENTENCODING=UTF8 in the environment of the server(!). Once I
unset that, I could reproduce the problem. This could be made a bit
more well-defined if we ran pg_regress with
Magnus Hagander wrote:
On 1 okt 2009, at 06.53, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
(Note that you would still need a non-default setting of
listen_addresses for -h machine_name to actually work.)
Jaime Casanova wrote:
it applies with some hunks, compiles fine and seems to work...
i'm still not sure this is what we need, some more comments could be helpful.
Yeah, that's the big question. Are the current capabilities (logging 'em
for waits deadlock timeout + dtrace hooks) enough?
Jeff Janes wrote:
The total wait time is equal to the max wait time (which are both
equal to l_end)?
One or both of those has to end up being wrong. At this stage, is
l_end supposed to be the last wait time, or the cumulative wait time?
Hmm - I may well have fat fingered the arithmetic,
On Sun, Sep 27, 2009 at 1:31 PM, Robert Haas robertmh...@gmail.com wrote:
As to #3, that's obviously gotta be fixed. If we're to further
consider this patch for this CommitFest, that fixing needs to happen
pretty soon.
Since it has been 6 days since I posted this and more than 2 weeks
since
On Thu, Oct 1, 2009 at 7:48 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Magnus Hagander mag...@hagander.net wrote:
I can certainly review the win32 encoding patch, but I was rather
hoping for some
Itagaki Takahiro wrote:
I removed hunks by sql_help.c and fix a typo in documentation.
An updated patch attached.
Brendan Jurd dire...@gmail.com wrote:
With the sql_help.c changes removed, the patch applied fine and
testing went well.
I noticed only the following in the new
Itagaki Takahiro wrote:
The point is *memory leak* in dblink when a query is canceled or
become time-out. I think it is a bug, and my patch could fix it.
Please see if this works for you.
Joe
Index: dblink.c
===
RCS file:
20 matches
Mail list logo
