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
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 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 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 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
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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 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
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-
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
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
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 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
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 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
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
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
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
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
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 24 Aug 2009, at 00:15, Greg Stark wrote:
On Sun, Aug 23, 2009 at 11:16 PM, Grzegorz
Jaskiewicz wrote:
ok folks, here's the last one for Today:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/
This does look better. The first one I looked at looks like a
legitimat
ok folks, here's the last one for Today:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/
tar ball with report can be downloaded from here: http://zlew.org/postgresql_static_check/postgresql_static_check_23rdAugust2009.tar.xz
(compressed with lzma's xz tool).
here's the pat
On 23 Aug 2009, at 20:31, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
for the record, here's patch that marks elog, etc as dead ends:
That does not look like the right thing at all, since now the checker
will believe that elog(NOTICE) and such don't return. I think you
n
this one should contain substantialy less false positives, because
error functions were marked as the 'never exit' points:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-9/
for the record, here's patch that marks elog, etc as dead ends:
Index: src/include/utils/elog.h
==
memory leak:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-46wcmJ.html#EndPath
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
about the false positives around 'null reference'. I'll try sticking
exit(1)'s at the end of each macro - and see if that makes most of
them go away.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-MAVb5D.html#EndPath
for a very positive one - at least from strict language point of view.
consider: float f = 1; f++; printf("%f\n", f);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On 23 Aug 2009, at 17:41, Greg Stark wrote:
Do you know how to teach clang about functions which never return?
http://clang-analyzer.llvm.org/annotations.html#attr_noreturn
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On 23 Aug 2009, at 17:41, Greg Stark wrote:
On Sun, Aug 23, 2009 at 4:57 PM, Grzegorz Jaskiewicz> wrote:
I am sure there's plenty of false positives, but I am also quite sure
there's many real errors on that list.
Do you know how to teach clang about functions which never retur
So,
after successful, and helpful Saturday with llvm's clang static
checker, I decided to run it against postgresql's source code.
Result can be seen at: http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/
.
One directory below is the tar file, with the report.
I am sure there'
On 16 Jul 2009, at 15:17, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
That's hardly going to improve readability for anyone. Also, it will
flat out not work for the catalog struct declarations. When we say
"bool relhasindex;" the compiler had better think that that
On 16 Jul 2009, at 14:53, Peter Eisentraut wrote:
On Thursday 16 July 2009 16:23:31 Grzegorz Jaskiewicz wrote:
On 16 Jul 2009, at 14:20, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
oh, another thing.
stdbool is C99 standard feature.
We are still targeting C89, not C99.
Another reason
On 16 Jul 2009, at 14:20, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
oh, another thing.
stdbool is C99 standard feature.
We are still targeting C89, not C99.
Another reason not to depend on stdbool is that, so far as I can see,
the standard does not promise that type _Bool has size = 1
oh, another thing.
stdbool is C99 standard feature. Not gcc extension.
Just in case, someone thinks otherwise.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 16 Jul 2009, at 12:52, Bernd Helmle wrote:
--On 16. Juli 2009 11:12:34 +0100 Grzegorz Jaskiewicz > wrote:
Now, for us, we will probably change it, but is there any reason for
postgresql nowadays not to use stdbool.h, apart from fact, that no
one
made an effort ? Having said t
Hi folks,
Today I got bitten a bit, trying to write C function for postgresql,
that also includes some of company's internal stuff. Needles to say,
our stuff defines BOOL, as well as postgresql's c.h include file.
Now, for us, we will probably change it, but is there any reason for
postgr
gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -
Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -
fwrapv -bundle -multiply_defined suppress regress.o -
bundle_loader ../../../src/backend/postgres -L../../../src/port -o
regress.so
cp ../../../contrib/
make -C catalog all
( echo src/backend/catalog/catalog.o src/backend/catalog/dependency.o
src/backend/catalog/heap.o src/backend/catalog/index.o src/backend/
catalog/indexing.o src/backend/catalog/namespace.o src/backend/catalog/
aclchk.o src/backend/catalog/pg_aggregate.o src/backend/catalog/
On 7 Jun 2009, at 03:27, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
On 6 Jun 2009, at 19:50, Tom Lane wrote:
We have five days.
I don't think we need testing, per se. The first step should be to
diff
the 8.3 and 8.4 versions of the various contrib .sql.in files and
determine
On 6 Jun 2009, at 19:50, Tom Lane wrote:
We have five days.
I don't think we need testing, per se. The first step should be to
diff
the 8.3 and 8.4 versions of the various contrib .sql.in files and
determine what changed. Any module whose .sql.in file hasn't changed
is definitely safe.
I
On 26 Apr 2009, at 16:22, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
tab-complete.c:666: warning: implicit declaration of function
'completion_matches'
Are you sure you have a real installation of readline? OSX is
notorious for providing a bogus one, particularly in older
rele
and a quick one on mac os x, which looks like it has something to do
with COMPLETE_WITH_LIST() and macros like that, and maybe with
completion_matches on mac os x. I don't get these on linux.
This is from gcc4.4 with -O3 (which obviously causes gcc to find more
potential warnings).
tab-com
On 25 Apr 2009, at 04:52, Robert Haas wrote:
blow the hash-join plan out of the water anyway... but Stephen Frost
was telling me at JDcon East that he sometimes sets it to something
like 8GB when he's the only user on his apparently-quite-awesome
hardware...)
For the record, because most querie
reloptions.c: In function âextractRelOptionsâ:
reloptions.c:731: warning: value computed is not used
heapam.c: In function âheapgettupâ:
heapam.c:458: warning: value computed is not used
heapam.c:458: warning: value computed is not used
heapam.c: In function âheapgettup_pagemodeâ:
heapa
if that's without -O3, than please retry it with. It will give even
more.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Does sql standard defines it ?
and another question, what about updating existing partitions, with no
need to drop/recreate ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 19 Apr 2009, at 18:28, Greg Stark wrote:
On Sun, Apr 19, 2009 at 6:24 PM, Grzegorz Jaskiewicz
wrote:
Will it also mean, that queries are going to be analyzed deeper ?
Ie, afaik I am able now to create plpgsql function, that tries to
run query
accessing non existent table, or columns
On 19 Apr 2009, at 17:42, Tom Lane wrote:
The attached proposed patch rips out plpgsql's handling of comments
and
string literals, and puts in scanner rules that are extracted from the
core lexer (but simplified in a few places where we don't need all the
complexity). The net user-visible e
On 18 Apr 2009, at 22:22, Tom Lane wrote:
This is mentioned in the release notes, but I suppose we'd better
promote it to the "observe the following incompatibilities" list...
This is a really funny one, because people naturally expect UNION
[ALL] to stay in the same order. Unlike the tabl
Btw, There was a "EXPLAIN XML" summer of code project, wasn't there ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 16 Apr 2009, at 19:41, Merlin Moncure wrote:
Is that because of how the output is formatted though, or because the
concepts are difficult to express? (I agree though, json is better
especially for structures that are possibly highly nested).
What I mean is that what postgresql displays curre
On 16 Apr 2009, at 16:21, David Fetter wrote:
On Thu, Apr 16, 2009 at 06:12:10AM +0100, Simon Riggs wrote:
I think the way to do this is to introduce plan output in XML
If we're going with a serialization, which I think would be an
excellent idea, how about one that's light-weight and human
On 11 Apr 2009, at 13:33, Hitoshi Harada wrote:
Maybe trigger functions should be displayed separately too than ?
You don't catch the point. The aggregate entries in pg_proc have
prosrc = 'aggregate_dummy', which means they're dummy and the entities
are stored in pg_aggregate. Triggers in pg_
On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
2009/4/11 David Fetter :
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
Yeah, but all the window functions are stored in pg_proc.
So are aggregate functions, and they have their own separate way of
being addressed in psql :)
On 3 Apr 2009, at 19:44, Lawrence, Ramon wrote:
I would be especially interested in using a shared memory hash table
that *all* backends can use - if the table is mostly read-only, as
dimension tables often are in data warehouse applications. That
would
give zero startup cost and significantl
On 11 Mar 2009, at 13:51, Marko Kreen wrote:
Linux kernel is moving to use -Os everywhere. AFAIK their argument is
that kernel code should not be doing anything CPU-intensive, thus
minimal cache usage is more important than unrolled loops.
This also seems to hint that -Os is not really approp
On 1 Mar 2009, at 00:52, Andrew Dunstan wrote:
We seem to have acquired a cardinality() function with almost no
discussion, and it has semantics that are a bit surprising to me. I
should have thought cardinality(array) would be the total number of
elements in the array. Instead, it seems
On 28 Feb 2009, at 11:37, Gregory Stark wrote:
Grzegorz Jaskiewicz writes:
Say I have:
select foo (
select foo from bar1
union all
select foo from bar2
union all
select foo from bar3
...
) a order by foo desc limit X;
(and I can give you few other examples around the same 'note&
Say I have:
select foo (
select foo from bar1
union all
select foo from bar2
union all
select foo from bar3
...
) a order by foo desc limit X;
(and I can give you few other examples around the same 'note', say
with when foo=N in outer subselect)
Would anyone consider such optimizat
tbh, I would add much more facts from internal changes, to improve
efficiency. Because that wouldn't be very convincing for , say my
managment (but than, what is..), etc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
yet more arguments, to let postgresql estimate those automatically.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9 Feb 2009, at 16:04, Tom Lane wrote:
Hmm. I think -qnoansialias corresponds to gcc's -fno-strict-aliasing,
which we *know* is necessary to build a working Postgres on recent gcc
versions. I have not checked the exact symptoms of -fstrict-aliasing
recently, but what you're reporting is def
On 7 Feb 2009, at 21:08, daveg wrote:
That this comes up "much to often" suggests that there is more than
near
zero interest. Why can only one compression library can be
considered?
We use multiple readline implementations, for better or worse.
I don't see anything wrong with using st
On 2 Feb 2009, at 14:50, Robert Haas wrote:
well, true - but also, statically allocated table, without any
predefined
size (with #DEFINE) , and no boundary check - is bad as well.
I suppose , this code is easy enough to let it be with your
changes, but I
would still call it not pretty.
W
On 1 Feb 2009, at 21:35, Robert Haas wrote:
On Sun, Feb 1, 2009 at 3:25 PM, Grzegorz Jaskiewicz > wrote:
I don't like the fact that you hardcoded that here. I know that you
are
trying to pass on few calls in one go here, but still... ugly.
Well, I think you'll find that using
disclaimer: I don't know that bit of postgresql code, in fact - this
is the first time I see it.
*** a/src/backend/optimizer/path/joinpath.c
--- b/src/backend/optimizer/path/joinpath.c
***
*** 473,478 match_unsorted_outer(PlannerInfo *root,
--- 473,481
if
On 1 Feb 2009, at 14:21, Stephen Frost wrote:
So if you have alot of roles granted, and even a couple attributes, it
gets ugly..
true.
I thought perhaps you guys want to go for table chart
USER\t PERM1\t PERM2\t PERM3
foo\to\tx\tx\o
bar\tx\to\to\x
Personaly that would work for me,
On 1 Feb 2009, at 11:07, Grzegorz Jaskiewicz wrote:
On 1 Feb 2009, at 10:58, David Fetter wrote:
I think Stephen meant that they should add a column to the output.
Stephen?
it's already there.
oh sorry, column - as in psql printout's column
yeah, doable too - lemme see i
On 1 Feb 2009, at 10:58, David Fetter wrote:
I think Stephen meant that they should add a column to the output.
Stephen?
it's already there.
try:
psql -E
\du
;]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
On 1 Feb 2009, at 10:25, Gregory Stark wrote:
I'm sorry if I was unclear. It needs to be in keywords.c but can
probably be
marked as UNRESERVED_KEYWORD there rather than RESERVED_KEYWORD.
In other words there are two places where you have to indicate
whether it's
reserved or not, keyword
On 23 Jan 2009, at 00:03, Tom Lane wrote:
Stephen Frost writes:
Seeing this list reminded me of a pet-peeve.. \du and \dg actually
show
the same info, that's fine, but neither of them show the rolcanlogin
value.
+1 for fixing that.
was it that easy, or I got it wrong?
:)
psql_du_
On 31 Jan 2009, at 17:22, David Fetter wrote:
Is this part of the SQL:2008? If not, is there something else that
is?
As far as I can see in the 'free' draft, no. Which is quite funny, cos
'DATABASE' keyword isn't there too..
Anyway. Looks like m$'s sybase clone got it, so I figure - at lea
On 31 Jan 2009, at 17:17, Gregory Stark wrote:
I don't see any reason offhand why it should have to be a reserved
word
though. You should be able to make it an UNRESERVED_KEYWORD. Oh, and
you'll
want to add it to the list of tokens in unreserved_keyword in gram.y
as well.
removing it fr
On 1 Feb 2009, at 00:05, Joshua Tolley wrote:
to add new syntax, you might consider writing a function instead. This
function might take parameters such as the privilege to grant and
the user to
grant it to, and be called something like this:
SELECT my_grant_function('someuser', 'someprivi
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
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
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: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
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
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 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
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-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-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 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
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,
1 - 100 of 180 matches
Mail list logo
