if (p1 > buf)
++ * --p1;
else {
++ * --p1; ???
does it even compile ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3 Mar 2010, at 17:41, Grzegorz Jaskiewicz wrote:
> if (p1 > buf)
>++ * --p1;
>else {
>
>
>
>
> ++ * --p1; ???
>
> does it even compile ?
Oh, I can see, that it is *(--p1)++ ,mea culpa.
Which doesn't change the fact, that the
On 25 Feb 2011, at 13:18, Robert Haas wrote:
> People coming from Oracle are not favorably
> impressed either by the amount of monitoring data PostgreSQL can
> gather or by the number of knobs that are available to fix problems
> when they occur. We don't need to have as many knobs as Oracle an
On 26 Feb 2011, at 14:45, Robert Haas wrote:
> On Sat, Feb 26, 2011 at 4:33 AM, Grzegorz Jaskiewicz
>>
>
> I don't think *anyone* is avoiding that approach. There is almost
> universal consensus here that auto-tuning is better than manual
> tuning, even to the extent
On 18 Mar 2011, at 21:12, Robert Haas wrote:
> While investigating Simon's complaint about my patch of a few days
> ago, I discovered that synchronous replication appears to slow to a
> crawl if fsync is turned off on the standby.
>
> I'm not sure why this is happening or what the right behavior
On 3 Aug 2011, at 19:20, David E. Wheeler wrote:
>
> Yeah, not sure whether or not to tweak the Makefile to use Clang. I guess not?
>
export CC=clang
./configure
...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
r_order_v5.patch ??
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
This is on dual ultra 2 sparc. with ultrawide 320 scsi drives. 512MB
ram.
I had to drop size of DB, because the DB drive is 4GB (I do welecome
bigger drives as donation, if someone asks - UWscsi 320).
here are my results. With only 4.2 patch (no maintain cluster order
v5 patch). If the v5 p
table; and select count(*) from
narrowtable; are the same - 1500
hth.
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Maybe we should add as resurce intensive check to ascii encoding(s),
that would even the score ;p
let's test mysql on this, and see how worse does it perform.
--
Grzegorz 'the evil' Jaskiewicz
evil C/evil C++ developer for hire
---(end of broadcast)-
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd
suggest to enable stats_block_level to see the effect on buffer
cache hit/
On Mar 21, 2007, at 5:22 PM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd
any idea how this patch is going to play with hot ? or should I just
give it a spin, and see if my world collapses :D
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
---(end of broadcast)---
TIP 4: Have you searched our list archives
? or perhaps someone already knows about
that kinda issue
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/
On Mar 21, 2007, at 11:25 PM, Tom Lane wrote:
Grzegorz Jaskiewicz <[EMAIL PROTECTED]> writes:
should I add it as a bug ?
Only if you can reproduce it in 8.2
okie dokie, I am moving the DB onto 8.2 next week (120M of rows, and
8.2 does sorting much faster).
--
Grzegorz Jaskiewic
okay, I got it. The main reason behind it - is that I do drop table
in transaction. Every 10 minutes. So during that period, when
'replication' is running - the thing becomes unstable, and this error
can appear.
--
Grzegorz Jaskiewicz
C/C++ freelanc
like to be able to safely run both
patches.
I will give both a go, once I get some free time here.
--
Grzegorz Jaskiewicz
starving C/C++ freelance for hire
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by d
re to look, PostgreSQL will just appear slow and tying up
resources.
Can we please package 8.2.4 and get it out the door?
+1
this is a show-stopper for me, I won't move production to 8.2, unless
that's fixed. Can't allow this to happen in production.
--
Grzegorz Jaskiewicz
what can't be purchased and silenced, should be killed with rain of law suits.
Microsoft does it, novell does it, sco does it, and oracle too.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql
s probably can tell why the first query won't work (subquery is not
allowed as limit's argument, why?).
cheers.
--
Grzegorz Jaskiewicz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On 21 Jan 2010, at 09:37, Dave Page wrote:
> In an attempt to pre-empt the normally drawn-out discussions about
> what the next version of PostgreSQL will be numbered. the core team
> have discussed the issue and following a lenghty debate lasting
> literally a few minutes decided that the next r
think also how people use SQL word , when calling ms sql server. They would
just say 'sql server' , and to some I had to explain that the little greedy
company didn't actually invented sql, hence it should be called ms sql
server...
so, -1 for dropping SQL word from me.
... and maybe the shed
Hey folks,
I would like to learn more about execution path for a simple query,
that is going to be changed by a rule. I want to find out, why output
of 'affected rows' isn't always altered properly in rules rewriting
inserts and updates.
Can someone give me simple guide on where should I lo
http://pastebin.com/d39eb7643
never had problems on mac os x with head, for last 4 years or so.
PGP.sig
Description: This is a digitally signed message part
On 2008-10-06, at 20:59, Grzegorz Jaskiewicz wrote:
Hey folks,
I would like to learn more about execution path for a simple query,
that is going to be changed by a rule. I want to find out, why
output of 'affected rows' isn't always altered properly in rules
rewrit
On 2008-10-08, at 01:57, Alvaro Herrera wrote:
Actually I find this to be a perfectly acceptable question for this
list. ISTM the answer, however, is to have a look at the
documentation
we have already in place ... perhaps starting with the Developer's FAQ
at http://wiki.postgresql.org/wi
current cvs head won't compile here, linking problem. I did try make
distclean, etc:
Undefined symbols:
"_dgettext", referenced from:
_errmsg_internal in elog.o
_elog_finish in elog.o
_errcontext in elog.o
_errhint in elog.o
_errdetail_log in elog.o
_errdet
On 2008-10-09, at 21:25, Alvaro Herrera wrote:
Grzegorz Jaskiewicz wrote:
current cvs head won't compile here, linking problem. I did try make
distclean, etc:
Undefined symbols:
"_dgettext", referenced from:
_errmsg_internal in elog.o
_elog_finish in elog.o
thickbook:backend gj$ gcc-4.2 -no-cpp-precomp -no-cpp-precomp -O2 -
Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-
statement -Wendif-labels -fno-strict-aliasing -fwrapv -L../../src/port
-Wl,-dead_strip_dylibs access/common/heaptuple.o access/common/
indextuple.o access/comm
On 2008-10-09, at 22:57, Alvaro Herrera wrote:
Grzegorz Jaskiewicz wrote:
On 2008-10-09, at 21:25, Alvaro Herrera wrote:
Yeah, my bad. What's the platform?
mac os x
Hmm, does your link line include -lintl? If not, does it successfully
link if you add it?
ld: library not foun
head compiles ok now, panic's over ;)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2008-10-10, at 16:01, Tom Lane wrote:
Well, this discussion started with the conventional wisdom about "be
conservative in what you send and liberal in what you accept". I'd
still resist emitting any UUID format other than the RFC-approved one,
but I don't see anything very wrong in being a
I think it will be as expensive to app to convert UUID to standard
format, as it would be too postgrsql.
But if psql does it - everyone would expect it to do it right. You
can't possibly detect all forms of screwed up design, and expect
application to pick it up.
All I say, is I think it wo
so I wonder, quite few times ppl asked me about my-word database TOP %
PERCENT (and I guess ms-word db has it too).
Now that postgres has limit(subselect) - postgresql can do the same
thing. But, using a count(*) in subselects isn't very efficient. The
backend gets information from limit X, s
that's a shame.
I figure, with the "WITH ... AS .." you can kind of speed up counts,
just by doing it once - now. But still, it would be great to be able
to use PERCENT, against estimate.
After all, imagine a table FOO with 5 rows, and something like this:
WITH c AS (select count(*)/4 as n f
On 2008-10-12, at 16:22, Hitoshi Harada wrote:
2008/10/12 Robert Haas <[EMAIL PROTECTED]>:
I wonder if this could be implemented using the window-function
infrastructure...
Yeah, actually window functions I am working now has percent_rank() or
something he wants. That is better than WITH cl
I won't send the full logs here, if someone's interested in it -
here's tar.bz2 version:
http://zlew.org/pg_regress.tar.bz2
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hmm, how could I miss that. but than:
thickbook:src gj$ ls -lahd /Users/gj/Projects/postgres-head/pgsql/src/
test/regress/results/
drwxr-xr-x 119 gj staff 4,0K 28 paź 19:14 /Users/gj/Projects/
postgres-head/pgsql/src/test/regress/results/
thickbook:src gj$ touch /Users/gj/Projects/postgre
On 2008-11-02, at 02:02, Greg Smith wrote:
Possible feedback topics:
-Setting the next round of values requires asking the user for some
input before making recommendations. Is it worth building a curses-
based interface to updating the values? That would be really
helpful for people w
On 2008-11-13, at 19:33, Greg Stark wrote:
A statistic target of 400 fir a specific column may make sense but
even then I would recommend monitoring performance to ensure it
doesn't cause problems. As a global setting it's, IMHO, ridiculous.
If that's the situation, me thinks you guys ha
On 2008-11-19, at 21:53, Gregory Stark wrote:
So based on Graeme Job's T-SQL hack over at thedailywtf.com I
adapted the
T-SQL code to Postgres and got this. Thought others might find it
amusing.
hohoho, nice. That's even better than mine "with recursive" PI
generator :)
--
Sent vi
this doesn't apply cleanly to head anymore, can you please post v21 ?
I would love to test it here :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2008-11-20, at 15:29, Peter Eisentraut wrote:
Well, the warning is explicitly put in there for this specific
function because you are supposed to process the return value. I'm
sure a more smarter compiler would even warn "variable is assigned a
value that is never used". ;-) (Note th
On 2008-11-20, at 11:08, Grzegorz Jaskiewicz wrote:
this doesn't apply cleanly to head anymore, can you please post v21 ?
I would love to test it here :)
bollocks, it's already in cvs head - isn't it ? ... :D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On 2008-12-06, at 11:29, David Lee Lambert wrote:
I use "ORDER BY random() LIMIT :some_small_number" frequently to get
a "feel"
for data. That always builds the unrandomized relation and then
sorts it. I
guess an alternate path for single-table queries would be to
randomly choose
a bl
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature request surfaced in the past?
I currently need this as an extra security measure for a libpq
client
On 2008-12-06, at 18:30, Andrew Chernow wrote:
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries.
I don't think this can be done right now ... or can it? Has this
feature request surfaced i
To be honest, for me back patching would mean only that I don't have
to recompile, and resend binaries to clients, after 8.1->8.3 upgrade
(to utilize enums, and domains).
I don't think it would break any apps tho.
so in my case, obviously +1 +1 :)
--
Sent via pgsql-hackers mailing list (pgs
if I may request one simple change/addition, Probably trivial to add,
but I don't have too much time to give away now to any other project
than one that pays my debts.
The default param that's in the middle. Would it be hard, or do anyone
objects against adding 'default' keyword there, so one
Ok, how about
CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[]
default '{6,7,8,90}');
and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}');
I have no idea what SQL standard says in that case, all I know is that
keyword DEFAULT exists in it, and is used in queries for sim
any news on that front ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2008-12-13, at 13:07, Markus Wanner wrote:
However, that is a marketing decision [1], which should not be mixed
with the technical discussion here. Speaking of a "synchronous commit"
is utterly misleading, because the commit itself is exactly the thing
that's *not* synchronous.
[1]: Som
On 2008-12-13, at 16:19, Tom Lane wrote:
I'm sure it's technically possible, but I see no redeeming social
value
in it ... we should pick one and quit repainting the bike shed.
+1000
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On 2008-12-16, at 07:58, ITAGAKI Takahiro wrote:
server says "INSERT 0 row" though rows are inserted into child
tables.
Technically this is correct since 0 rows were inserted in the parent
table.
Yes, but users expect non-0 result normally. Some O/R mapping tools
also checks the result ex
create table a(a int not null);
insert into a(a) select generate_series(1,600);
create table b as select * from a where a%10 <> 0;
create index fooa on a(a);
alter table b alter column a set not null;
create index foob on b(a);
vacuum analyze verbose;
gj=# explain select a.a from a where a
all I know, is that the same query will work on 8.3 in reasonably
acceptable time frame.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
true, but as soon as I drop indices on both tables:
root=# explain analyze select a.a from a where a not in (select a from
b);
QUERY PLAN
--
and the plan on 8.4:
gj=# explain select a.a from a where a not in (select a from b);
QUERY PLAN
-
Seq Scan on a (cost=99035.00..257874197565.00 rows=300 width=4)
Filter: (NOT (subplan))
On 2008-12-19, at 13:07, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
Filter: (NOT (hashed subplan))
^^
If 8.3 does that, and 8.4 doesn't, it's most likely because you are
using different work_mem settings.
you're right, as always :)
My point is,
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw and we just have to live with it.
--
Sent via pgsql-hackers mailing lis
On 2008-12-22, at 21:07, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation
On 2008-12-22, at 22:35, Dawid Kuroczko wrote:
atlantis=> CREATE OR REPLACE FUNCTION foo_trigger() RETURNS trigger AS
$$ BEGIN UPDATE bar SET t=NEW.t WHERE i=NEW.i; RETURN NULL; END; $$
LANGUAGE plpgsql;
atlantis=> CREATE TRIGGER foo_update BEFORE UPDATE ON foo FOR EACH ROW
EXECUTE PROCEDURE f
WITH RECURSIVE tree(b, l, lv) AS
(
(
WITH RECURSIVE t(b, l) AS
(
select b/11.6, 0 AS l from (select
generate_series(0,30)::float8 b union all select generate_series(30,0,
-1)::float8 b) ziew
UNION ALL
select (b*1.06), l+1 FROM t WHERE l < 3
)
select b, l,
On 2009-01-12, at 16:48, Dave Page wrote:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake
wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project
management
decision we've had several times before: are we willing to slip the
On 2009-01-18, at 09:56, Peter Eisentraut wrote:
On Sunday 18 January 2009 08:28:51 Tom Lane wrote:
Yeah, the risk this is trying to guard against is variables
containing
"%" unexpectedly. Even if that's not possible, it requires some work
to verify and it's a bit fragile. I didn't look at
On 24 Aug 2009, at 14:40, Peter Eisentraut wrote:
On mån, 2009-08-24 at 00:42 +0100, Grzegorz Jaskiewicz wrote:
--enable-cassert, enabled, and also added exit_* in pg_dump to list
of functions that never return.
A few more functions to mark noreturn: DateTimeParseError(), and
die_horribly
On 27 Aug 2009, at 10:46, Paul Matthews wrote:
Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
geo_ops.c. None of them of any particular excitement or of earth
shattering nature. A patch is attached below that should correct
these.
(The more little issue we eliminate
heh, sorry folks for the noise again :/
There was a fair amount of false positives there - due to nature of
Assert() macro. Mainly, since assert_enabled is a runtime variable,
not a macro (which I sadly overlooked).
So, hardcoding it to (1) (using CPP) removed quite few false positives.
Ne
new one at http://zlew.org/postgresql_static_check/scan-build-2009-08-29-3/
archive at :
http://zlew.org/postgresql_static_check/postgresql_static_check_29thAugust2009.tar.xz
as always, comments are welcomed. And constructive explanation of any
wrong-results will be relayed to clang-checker d
On 29 Aug 2009, at 17:35, Greg Stark wrote:
We still have things like this showing "division by zero":
Assert(activeTapes > 0);
1913 slotsPerTape = (state->memtupsize - state->mergefirstfree) /
activeTapes;
It looks like if you marked ExceptionalCondition() as never returning
then it sho
On 29 Aug 2009, at 18:05, Greg Stark wrote:
Oh, I think I see what's happening. Our assertions can still be turned
off at run-time with the variable assert_enabled.
Index: src/include/postgres.h
===
RCS file: /projects/cvsroot/pg
okay, I think I nailed the assert part right. (3rd iteration, about
time...).
as usual: http://zlew.org/postgresql_static_check/scan-build-2009-08-30-2/
archive one dir up.
the current patch attached.
postgres_checker_patch.patch.bz2
Description: BZip2 compressed data
--
Sent via pgsql-ha
On 30 Aug 2009, at 15:46, Greg Stark wrote:
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
well, all I can do is this: http://llvm.org/bugs/show_bug.cgi?id=4832
I find it hard to belive tho
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 30 Aug 2009, at 18:07, Greg Stark wrote:
On Sun, Aug 30, 2009 at 5:58 PM, Grzegorz Jaskiewicz> wrote:
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
Argh. That didn't help at all. hm, I suppose instead of (exi
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
please don't tell me that this is bogus: http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
?
How come ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On 30 Aug 2009, at 19:14, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
please don't tell me that this is bogus:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
Yes, it's bogus. ctid is never passed as NULL. It might point at
a
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
On 2 Sep 2009, at 21:38, Alvaro Herrera wrote:
Grzegorz Jaskiewicz escribió:
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
What's with the "analyzer failures"? Did you sub
clang developers were quick to iron out their bugs, here's Today report:
http://zlew.org/postgresql_static_check/scan-build-2009-09-04-1/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
usual round of updates to the scan report.
Today's report available at:
http://zlew.org/postgresql_static_check/scan-build-2009-09-12-1/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 14 Sep 2009, at 06:04, Tom Lane wrote:
Looks like the clang guys still have some work to do.
Thanks Tom, reported to clang dev's .
meanwhile, since quite a lot stuff went in over weekend, and since
Yesterday, new report at:
http://zlew.org/postgresql_static_check/scan-build-2009-09-1
Anyone knows what's the latest on that patch ?
To be honest, this was the thing that I was looking forward most in
8.5 ... (and probably not only me alone).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
http://llvm.org/bugs/show_bug.cgi?id=4979
will see, one issue is already fixed. I'll retry when the second one
is too.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via
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 (pgsql-hackers@postgresql.org
On 24 Oct 2009, at 14:41, Magnus Hagander wrote:
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that something like a tuning
tool, or pgadmin, for example can dro
On 29 Oct 2009, at 02:15, Itagaki Takahiro wrote:
I'd like to improve partitioning feature in 8.5.
Kedar-san's previous work is wonderful, but I cannot see any updated
patch.
http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com
So, I'll take o
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
regression.diffs.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 13 Nov 2009, at 19:39, Tom Lane wrote:
> Peter Eisentraut writes:
>> On fre, 2009-11-13 at 15:05 +0100, Grzegorz Jaśkiewicz wrote:
>>> As per Tom's - yes, this laptop has LANG set to UTF8 Polish. Setting
>>> it back to EN actually makes this error go away.
>
>> The Polish locale isn't suppo
On 21 Nov 2009, at 02:56, Josh Berkus wrote:
>
>> Would a patch that changes that have any chance of being accepted? Or is
>> the gain (not having to repeat the DEFAULT clause, and being able to
>> maintain it at one place instead of many) considered too small compared
>> to the risk of breaking
On 2009-01-24, at 15:33, Bruce Momjian wrote:
The PostgreSQL community is considering including security
enhancements
in Postgres 8.4, e.g. row-level permissions and SE-Linux security.
However, to evaluate the patch and its usefulness, we need security
experts who want to use this capability
On 2009-01-25, at 09:04, Simon Riggs wrote:
On Sat, 2009-01-24 at 21:58 +0200, Heikki Linnakangas wrote:
When replaying a DROP TABLE SPACE, you first try to remove the
directory, and if that fails, you assume that it's because it's in
use
as a temp tablespace in a read-only transaction.
On 2009-01-26, at 17:34, Kevin Grittner wrote:
. It may not
surprise someone who is intimately familiar with PostgreSQL internals
for a single SELECT statement to see PART of a transactions work, but
it would surprise most users, and is certainly not compliant with the
standard.
+1000
--
Sen
Hey folks,
I am trying to add "GRANT SELECT ON ALL TABLES" to postgres, as it has
been quite few times now - where I had to write a procedure for that.
I kind of looked around, and more or less know how to approach it. But
I am stuck on parser :), yes - parser.
Can someone walk me through a
On 31 Jan 2009, at 16:46, Grzegorz Jaskiewicz wrote:
+ {"table", TABLES, RESERVED_KEYWORD},
Gaaah, a typo...
:(
(another useless post to -hackers, by myself).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On 31 Jan 2009, at 17:17, Gregory Stark wrote:
Grzegorz Jaskiewicz writes:
You're going to kick yourself, but:
{"table", TABLE, RESERVED_KEYWORD},
+ {"table", TABLES, RESERVED_KEYWORD},
^
I don't see any reason offhand why i
from http://wiki.postgresql.org/wiki/Todo:
[E] <>Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command
The proposed syntax is: GRANT SELECT ON ALL TABLES IN public TO
phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser;
--
Sent via pgsql-hackers mailin
On 31 Jan 2009, at 17:30, Andrew Dunstan wrote:
But the syntax you posted does not do this at all. Where does it
restrict the grant to a single schema, like the syntax above?
I am just starting the attempt here, obviously since I admit that my
parser skills are next to none - I didn't addres
On 31 Jan 2009, at 17:28, David Fetter wrote:
On Sat, Jan 31, 2009 at 05:24:15PM +, Grzegorz Jaskiewicz wrote:
from http://wiki.postgresql.org/wiki/Todo:
I see the TODO item, but I don't see anything in the SQL standard,
which I think is something we should explore before mak
1 - 100 of 180 matches
Mail list logo
