On Tue, Dec 15, 2009 at 5:30 AM, Greg Smith g...@2ndquadrant.com wrote:
When I look at http://www.pgadmin.org/support/ for example it suggests the
right list. I only see this one listed in the Translation section, as the
place to ask to get added to the translators list. Does anyone know
Le mardi 15 décembre 2009 à 06:30:15, Greg Smith a écrit :
[...]
BTW, this list is listed as the list for tech questions in the pgAdmin
tips, therefore if you don't want to be disturb, you might want to
remove it from the pgAdmin tips.
When I look at http://www.pgadmin.org/support/ for
Looks like Andrew Dunstan didn't want to go public...
Fred
-- Forwarded message --
From: Fred Janon fja...@gmail.com
Date: Tue, Dec 15, 2009 at 10:03
Subject: Re: [HACKERS] pgAdmin III: timestamp displayed in what time zone?
To: Andrew Dunstan and...@dunslane.net
Thanks for
Hot Standby node can freeze when startup process calls LockBufferForCleanup().
This bug can be reproduced by the following procedure.
0. start Hot Standby, with one active node(node A) and one standby node(node B)
1. create table X and table Y in node A
2. insert several rows in table X in node
Hot Standby node can freeze when startup process calls LockBufferForCleanup().
This bug can be reproduced by the following procedure.
0. start Hot Standby, with one active node(node A) and one standby node(node B)
1. create table X and table Y in node A
2. insert several rows in table X in node A
On 12/15/09, Kurt Harriman harri...@acm.org wrote:
Attached is a revised patch, offered for the 2010-01 commitfest.
It's also available in my git repository in the submitted branch:
http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=shortlog;h=refs/heads/submitted
In this
* Robert Haas (robertmh...@gmail.com) wrote:
I think there was a previous discussion of this when Heikki first
posted the issue to -hackers.
There was, it's now linked off the http://wiki.postgresql.org/wiki/RLS
page (as well as this thread). Feel free to add other threads, update
with your
On Tue, Dec 15, 2009 at 7:28 AM, to...@tuxteam.de wrote:
The situation is even more restricted with floats (they are much
smaller; thus one could say that they're more discrete than strings,
even). Problem with floats is -- the granule is not the same size over
the whole range (nasty), and
Hi,
here's another patch that aims to fix auto-prepare.
The reason is, that in the project porting from Informix,
a small test case that used a cursor and two small SELECTs
issued for every record retrieved by the cursor showed that
for this case, the ESQL compiled binary finished about 60%
*ahem*
You double-post a query *knowing* you shouldn't (otherwise why the
sorry?), compounding the error by not picking the right list at all. I
chide you for it privately, not to hide my actions but to keep
irrelevant traffic on the list down, and you then decide it's proper to
post my
Hi
HEAD fails to compile in 64-bit mode on Mac OS X 10.6 with gcc 4.2 and
-Werror.
What happens is that INT64_FORMAT gets defined as %ld (which is
correct - long and unsigned long are 64 bits wide on x86_64), but
the check for a working 64-bit int fails, causing INT64_IS_BUSTED to get
defined
Takahiro Itagaki wrote:
Here is an updated patch rebased to the latest CVS HEAD.
One remaining concern is VERBOSE. Log messages by FULL (rewrite) are less
verbose than FULL INPLACE. The same can be said for CLUSTER VERBOSE, though.
I don't have any plans to make CLUSTER more verbose in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Dec 15, 2009 at 01:09:02PM +, Greg Stark wrote:
[...]
In fact, as I only recently found out, one of the design goals of IEEE
floats was specifically that they sort lexicographically and use every
bit pattern. So you can alwys get the
to...@tuxteam.de writes:
(and as Andrew Dunstan pointed out off-list: I was wrong with my bold
assertion that one can squeeze infinitely many (arbitrary length)
strings between two given. This is not always the case).
Really? If the string length is unbounded I think you were right.
Greg Stark gsst...@mit.edu writes:
In fact, as I only recently found out, one of the design goals of IEEE
floats was specifically that they sort lexicographically and use every
bit pattern. So you can alwys get the next float by just
incrementing your float as an 64-bit integer. Yes that
Florian G. Pflug f...@phlo.org writes:
configure fails to recognize long as a working 64-bit type because the
does_int64_work configure test produces warning due to a missing return
value declaration for main() and a missing prototype for
does_int64_work(). (Aain, those warning are turned into
On Mon, Dec 14, 2009 at 10:21 PM, Stephen Frost sfr...@snowman.net wrote:
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
You are fine. I was just saying that at a time I was one of the few
loud voices on this, and if this is going to happen, it will be because
we have a team that wants to
On Tue, Dec 15, 2009 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
In fact, as I only recently found out, one of the design goals of IEEE
floats was specifically that they sort lexicographically and use every
bit pattern. So you can alwys get the next float
On 15.12.09 16:02 , Tom Lane wrote:
Florian G. Pflugf...@phlo.org writes:
configure fails to recognize long as a working 64-bit type
because the does_int64_work configure test produces warning due to
a missing return value declaration for main() and a missing
prototype for does_int64_work().
2009/12/15 Tom Lane t...@sss.pgh.pa.us:
to...@tuxteam.de writes:
(and as Andrew Dunstan pointed out off-list: I was wrong with my bold
assertion that one can squeeze infinitely many (arbitrary length)
strings between two given. This is not always the case).
Really? If the string length is
Robert Haas robertmh...@gmail.com writes:
I also have to say that I'm very skeptical of the argument
that there is only a small list of types people will want this for.
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide
On 12/15/09, Florian G. Pflug f...@phlo.org wrote:
On 15.12.09 16:02 , Tom Lane wrote:
Florian G. Pflugf...@phlo.org writes:
configure fails to recognize long as a working 64-bit type
because the does_int64_work configure test produces warning due to
a missing return value
On Tue, Dec 15, 2009 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I also have to say that I'm very skeptical of the argument
that there is only a small list of types people will want this for.
I'm not sure that anyone has argued that. I did
Nicolas Barbier nicolas.barb...@gmail.com writes:
Assuming lexicographical ordering (first different character
determines order; end-of-string is sorted before anything else),
consider the following two strings:
whatever
and
same whatever as before + the character with the lowest value in
On 15.12.09 15:52 , Tom Lane wrote:
to...@tuxteam.de writes:
(and as Andrew Dunstan pointed out off-list: I was wrong with my
bold assertion that one can squeeze infinitely many (arbitrary
length) strings between two given. This is not always the case).
Really? If the string length is
On Tue, Dec 15, 2009 at 02:19:19PM +0100, Boszormenyi Zoltan wrote:
here's another patch that aims to fix auto-prepare.
...
--- pgsql.6/src/interfaces/ecpg/preproc/output.c 2009-12-15
13:12:37.0 +0100
*** hashline_number(void)
*** 106,112
}
void
!
Tom Lane wrote:
So the long and the short of it is that next/previous are not
going to work for string types, maxlength or no maxlength.
Even more importantly, I strongly doubt they would be of the slightest
practical value.
cheers
andrew
--
Sent via
Michael Meskes írta:
On Tue, Dec 15, 2009 at 02:19:19PM +0100, Boszormenyi Zoltan wrote:
here's another patch that aims to fix auto-prepare.
...
--- pgsql.6/src/interfaces/ecpg/preproc/output.c 2009-12-15
13:12:37.0 +0100
*** hashline_number(void)
*** 106,112
Zdenek Kotala wrote:
Bernd Helmle píše v po 14. 12. 2009 v 20:42 +0100:
Oh, and i was under the opinion the last discussions were about executor
probes only (note the patch is split up into two parts now, SLRU and
executor probes). The latter won't be fixed, but it seems the SLRU part at
We're down to five patches that are ready for a committer still on the
table:
-New VACUUM FULL
-tsearch parser inefficiency with urls or emails
-ProcessUtility_hook
-Aggregate ORDER BY support
-Hot Standby
I just bounced Streaming Replication forward to the next CF, and
specifically noted the
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide discrete
behavior (ie, with next/previous functions) and the rest could have
continuous behavior (without that
On 12/15/09 1:05 AM, Takahiro Itagaki wrote:
Here is an updated patch rebased to the latest CVS HEAD.
One remaining concern is VERBOSE. Log messages by FULL (rewrite) are less
verbose than FULL INPLACE. The same can be said for CLUSTER VERBOSE, though.
I don't have any plans to make CLUSTER
Andrew Gierth and...@tao11.riddles.org.uk writes:
Updated version of the aggregate order by patch.
Applied with some editorialization. The main change I made was to get
rid of all the ad-hoc DISTINCT handling in parse_agg.c and use
transformDistinctClause() instead. This exposed what I believe
On Tue, Dec 15, 2009 at 12:27 PM, Greg Smith g...@2ndquadrant.com wrote:
-New VACUUM FULL
I get the impression there is still some discussion that needs to
happen about the design of this. I think we should mark it Returned
with Feedback for now, and let whoever ends up working on it resubmit
running with log_checkpoints = on
pg_ctl -D foo -m fast stop
log says
LOG: received fast shutdown request
LOG: aborting any active transactions
LOG: shutting down
LOG: restartpoint starting: shutdown immediate
Some of us know that the immediate word refers to the restartpoint
request,
On Tue, Dec 15, 2009 at 12:19 PM, Simon Riggs si...@2ndquadrant.com wrote:
running with log_checkpoints = on
pg_ctl -D foo -m fast stop
log says
LOG: received fast shutdown request
LOG: aborting any active transactions
LOG: shutting down
LOG: restartpoint starting: shutdown immediate
Jeff Davis pg...@j-davis.com writes:
If I'm correct, continuous ranges always need two extra bits of storage
for the exclusivity. But for timestamps, that means 16 bytes (2 x 8-byte
timestamp) turns into 17 bytes, which is really more like 20 or 24 bytes
with alignment.
You probably need some
Greg Smith g...@2ndquadrant.com writes:
We're down to five patches that are ready for a committer still on the
table:
-New VACUUM FULL
-tsearch parser inefficiency with urls or emails
-ProcessUtility_hook
-Aggregate ORDER BY support
-Hot Standby
Aggregate ORDER BY is in. I will pick up
I get this when testing prepared transactions, which looks like it is
unrelated to Hot Standby.
2009-12-15 17:28:08 GMT[10385]LOG: archive recovery complete
2009-12-15 17:28:08 GMT[10428]LOG: checkpoint starting: end-of-recovery
immediate wait
2009-12-15 17:28:08 GMT[10428]DEBUG: creating and
Just to make those who care aware of it, here is Michael Cahill's
Doctoral Thesis based on implementing Serializable Snapshot
Isolation in InnoDB using a refined version of the techniques
previously used in the Berkley DB (and previously discussed on this
list):
http://hdl.handle.net/2123/5353
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide discrete
behavior (ie, with next/previous functions) and the rest could have
continuous behavior
Robert Haas wrote:
On Tue, Dec 15, 2009 at 12:27 PM, Greg Smith g...@2ndquadrant.com wrote:
-New VACUUM FULL
I get the impression there is still some discussion that needs to
happen about the design of this. I think we should mark it Returned
with Feedback for now, and let whoever
On Tuesday 15 December 2009 20:44:36 Greg Smith wrote:
As for the tsearch improvements, not to trivialize the patch, but I
think this one will survive being committed between alpha3 CF 2010-01
if it doesn't make it in this week. Teodor can work on getting that
committed when he has time, I
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
Would it be OK if we handled float timestamp ranges as continuous
and int64 timestamps discrete?
That sounds like a recipe for disaster. Whatever timestamp
I applied this patch after a little bit of editorialization concerning
the points mentioned in this discussion:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 9, 2009 at 9:33 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
Why does
On tis, 2009-12-15 at 16:15 +0100, Florian G. Pflug wrote:
Alternatively - is there a way to use -Werror only for building the
actual sources, not the configure tests? I didn't find one, but my
autoconf-fu is pretty limited...
I always build with
pgmake='make COPT=-Werror -Wno-inline'
(The
Greg Smith g...@2ndquadrant.com writes:
We're down to five patches that are ready for a committer still on the
table:
-tsearch parser inefficiency with urls or emails
I just looked at this one and concluded that it was pretty harmless;
will commit it.
regards, tom
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Andrew Gierth and...@tao11.riddles.org.uk writes:
Updated version of the aggregate order by patch.
Tom Applied with some editorialization. The main change I made was
Tom to get rid of all the ad-hoc DISTINCT handling in parse_agg.c
Tom and
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andres Freund and...@anarazel.de wrote:
[concerns addressed in new patch version]
Looks good to me. I'm marking this Ready for Committer.
Applied with minor editorialization --- improving the comments mostly.
Andrew Gierth and...@tao11.riddles.org.uk writes:
Query-level DISTINCT shouldn't allow columns in the order by that
aren't in the select list because those columns _do not exist_ at the
point that ordering logically takes place (even though in the
implementation, they might).
This isn't the
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Query-level DISTINCT shouldn't allow columns in the order by that
aren't in the select list because those columns _do not exist_ at
the point that ordering logically takes place (even though in the
implementation, they might).
This isn't the
Andrew Gierth and...@tao11.riddles.org.uk writes:
Notice that there are cases where agg(distinct x order by x) is
nondeterministic while agg(distinct x order by x,y) is deterministic.
Well, I think what you're really describing is a case where you're using
the wrong sort opclass. If the
On 12/15/2009 4:05 AM, Marko Kreen wrote:
On 12/15/09, Kurt Harrimanharri...@acm.org wrote:
Attached is a revised patch, offered for the 2010-01 commitfest.
It's also available in my git repository in the submitted branch:
David Fetter da...@fetter.org writes:
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
As for the extra bits, would it be better to just require continuous
ranges to be either [] or [)? But I don't know which would be
preferred. My inclination would be toward [), but Tom seemed to
Peter Eisentraut pete...@gmx.net writes:
I have also tried in the past to pass -Werror through configure, but
that caused too many problems.
Is it your opinion that we shouldn't bother fixing this particular
test? I was on the fence about it myself. I don't want to promise
that configuring
On Tue, 2009-12-15 at 13:15 -0500, Tom Lane wrote:
You probably need some flag bits anyway, so flailing frantically to
avoid that doesn't seem like a profitable use of time.
I think need and flailing are both a little too strong here. The
biggest use case will almost certainly be ranges of
Hello
I am looking on new feature - ORDER clause in aggregate, and I thing,
so we are able to effectively implement some non standard, but well
known aggregates.
a) function median - it is relative frequent request - with usually
slow implementation
b) function listagg (it is analogy of
On 12/15/09, Kurt Harriman harri...@acm.org wrote:
On 12/15/2009 4:05 AM, Marko Kreen wrote:
Unless it is some popular compiler (as in actual use) it is
premature complexity. Please remove that.
Microsoft's compilers are in actual use, and some might even
say they are popular. For
On 12/15/09, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
I have also tried in the past to pass -Werror through configure, but
that caused too many problems.
Is it your opinion that we shouldn't bother fixing this particular
test? I was on the fence
On Tue, 2009-12-15 at 18:49 +, Simon Riggs wrote:
This looks like the code is setting the parent to be zero.
[Sorry, that comment is completely off, misread the line number.]
The assertion is failing because the parent entry for that subxid had
already been set.
Investigating how that
On 12/15/2009 1:31 PM, Marko Kreen wrote:
Do you have actual proof that MSVC launches warnings on unused
static inline functions? Not static, but static inline.
Yes, I tried it, and that's why I did it this way.
If yes, indeed we need to fix it. MSVC is broken then, but it does
not matter
Jeff Davis pg...@j-davis.com writes:
I think need and flailing are both a little too strong here. The
biggest use case will almost certainly be ranges of timestamps, and most
of those people will have no use for flag bits (or if they do, it might
not be worth an 8-byte-per-value overhead).
David Fetter wrote:
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
Would it be OK if we handled float timestamp ranges as continuous
and int64 timestamps discrete?
That sounds like a recipe for disaster.
On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
That sounds like a recipe for disaster. Whatever timestamp ranges
are, float and int64 should be treated the same way so as not to get
surprises due to implementation details.
It's a compile-time option that will change the semantics of
On 12/15/09, Kurt Harriman harri...@acm.org wrote:
On 12/15/2009 1:31 PM, Marko Kreen wrote:
Do you have actual proof that MSVC launches warnings on unused
static inline functions? Not static, but static inline.
Yes, I tried it, and that's why I did it this way.
Oh. Ok then.
--On 15. Dezember 2009 12:10:09 -0500 Greg Smith g...@2ndquadrant.com
wrote:
But I'm afraid we're already out of time for this one if you're still
tweaking the probes here. With a functional change like that, our
normal process at this point would be to have the reviewer re-evaluate
things
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
FWIW, I think it would be a good idea to treat timestamps as
continuous in all cases.
I disagree. There is a lot of value in treating timestamp ranges as
discrete.
One big reason is that the ranges
On Tue, Dec 15, 2009 at 10:28:49PM +0100, Pavel Stehule wrote:
Hello
I am looking on new feature - ORDER clause in aggregate, and I thing,
so we are able to effectively implement some non standard, but well
known aggregates.
a) function median - it is relative frequent request - with
On tis, 2009-12-15 at 16:22 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I have also tried in the past to pass -Werror through configure, but
that caused too many problems.
Is it your opinion that we shouldn't bother fixing this particular
test? I was on the fence
Scott Bailey arta...@comcast.net writes:
Ok, let me give an example of what we can do with the current
implementations that would not be possible with timestamps if we
implement as suggested. ...
The function below takes two period arrays that can have overlapping and
adjacent elements. It
Peter Eisentraut pete...@gmx.net writes:
So to summarize, this is just a bad idea. Creating a less obscure way
to use -Werror might be worthwhile, though.
I suppose we could add --with-Werror but it seems pretty specialized
to me. A more appropriate solution would allow the user to provide
Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
FWIW, I think it would be a good idea to treat timestamps as
continuous in all cases.
I disagree. There is a lot of value in treating timestamp ranges as
discrete.
One big reason
If this were an amazingly
short and beautiful piece of code, it might support your argument,
but it's neither.
Well we can't all be arrogant brainiacs.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Dec 11, 2009, at 8:44 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Ashish wrote:
I am thinking about starting with the following TODO item:
-- Have EXPLAIN ANALYZE issue NOTICE messages when the estimated
and actual row counts differ by a specified percentage.
I even have
I wrote:
The proposed problem is certainly soluble without any assumptions
of discreteness.
To be concrete, I think it could be approached like this:
Assume the datatype provides a built-in function
period_except(p1 period, p2 period) returns setof period
which can return zero, one,
On Tue, 2009-12-15 at 17:17 -0500, Tom Lane wrote:
Actually, that is exactly one of the reasons why what you propose is
a *bad* idea. You want to institutionalize application dependence on
a non-portable implementation detail, namely the granularity of machine
representation of what's in
On 12/15/09 2:40 PM, Scott Bailey wrote:
If this were an amazingly
short and beautiful piece of code, it might support your argument,
but it's neither.
Well we can't all be arrogant brainiacs.
Tom, Scott,
Let's keep it constructive here. Thanks!
--Josh
--
Sent via pgsql-hackers
On Dec 15, 2009, at 5:40 PM, Jeff Davis wrote:
If you think I'm proposing that we drop inclusivity/exclusivity before
telling the application, that's not what I'm proposing at all. I'm
proposing that, at least in some circumstances, it's important to be
able to display the same value in
On Dec 15, 2009, at 11:34 AM, Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide discrete
behavior (ie, with next/previous functions) and the rest
On Dec 15, 2009, at 3:40 PM, Jeff Davis wrote:
Based on the premise that timestamps are a continuous value and the
granularity/precision is entirely an implementation detail, you're
right. But I disagree with the premise, at least in some cases that I
think are worthwhile.
The argument is,
Alvaro Herrera alvhe...@commandprompt.com wrote:
Hmm. With this patch, if I do vacuumdb -f it will not vacuum the
special system catalogs that can only be vacuumed with INPLACE, correct?
No. It will vacuum normal tables with FULL (rewrite), and system catalogs
with FULL INPLACE. FULL vacuums
Tom Lane wrote:
I wrote:
The proposed problem is certainly soluble without any assumptions
of discreteness.
To be concrete, I think it could be approached like this:
Assume the datatype provides a built-in function
period_except(p1 period, p2 period) returns setof period
which can
On Tue, 2009-12-15 at 18:06 -0600, decibel wrote:
Now that varlena's don't have an enormous fixed overhead, perhaps it's
worth looking at using them. Obviously some operations would be
slower, but for your stated examples of auditing and history, I
suspect that you're not going to notice the
On Tue, 2009-12-15 at 18:03 -0600, decibel wrote:
I think it would help the discussion if you could provide some real
examples. I suspect you're thinking of things like scheduling apps,
where it's important to be able to do things like what's the next
available time slot?. There are probably
On Tue, 2009-12-15 at 16:08 -0800, Christophe Pettus wrote:
The argument is, in essence:
DECIMAL is continuous.
DECIMAL(10,3) is discrete.
timestamptz in general is a continuous value (unless we're talking
Planck times :) ). There is no way for us to guarantee that
On 15.12.09 23:38 , Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
So to summarize, this is just a bad idea. Creating a less obscure
way to use -Werror might be worthwhile, though.
I suppose we could add --with-Werror but it seems pretty
specialized to me. A more appropriate
On 12/15/2009 2:09 PM, Marko Kreen wrote:
Oh. Ok then. Force-inline seems better fix as we may want to use
it for other reasons too (converting big macros).
So it seems like a good moment to solve it for gcc too.
Is ordinary inlining not sufficient?
If deluxe inlining is something that
(2009/12/16 0:03), Robert Haas wrote:
But these patches are, unfortunately, not technically excellent.
There have been multiple reviews of these patches that have produced
extensive laundry lists of items to be fixed. In the ordinary course
of events, that leads to one of two things
On Tue, Dec 15, 2009 at 3:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Tom Lane wrote:
The very, very large practical problem with this is that if you decide
to change the behavior at any time, the only way to be sure that the WAL
receiver is using the right libpq
[Please ignore the previous incomplete version of this reply, which I
sent by mistake. Sorry for the list noise.]
On 12/15/2009 2:09 PM, Marko Kreen wrote:
Oh. Ok then. Force-inline seems better fix as we may want to use
it for other reasons too (converting big macros).
So it seems like
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman harri...@acm.org wrote:
Your worry ii) can be ignored, managing to compile on such
compilers is already overachievement.
I think so too. With your opinion added to mine, do we constitute a
consensus of the pg community? Someone might object
The attached patch is a draft for the discussion.
It cleans up the existing PG privileges checks related to databases
and schemas, and consolidates points where it applies privileges
checks as a groundwork for the upcoming security framework.
We have tried a few approaches to implement SE-PgSQL
It is a cleanup patch apart from SELinux and security framework.
Now, EnableDisableRule() checks ownership of the relation which
owns the rewrite rule to be enabled/disabled.
But it has the following call path, and this check is already done
in the ATPrepCmd().
ATExecCmd()
-
The patch was not attached...
(2009/12/16 15:15), KaiGai Kohei wrote:
It is a cleanup patch apart from SELinux and security framework.
Now, EnableDisableRule() checks ownership of the relation which
owns the rewrite rule to be enabled/disabled.
But it has the following call path, and this
2009/12/15 David Fetter da...@fetter.org:
On Tue, Dec 15, 2009 at 10:28:49PM +0100, Pavel Stehule wrote:
Hello
I am looking on new feature - ORDER clause in aggregate, and I thing,
so we are able to effectively implement some non standard, but well
known aggregates.
a) function median - it
This patch fixes a problem discussed earlier.
Now, FindConversion() which is only called from FindConversionByName()
checks ACL_EXECUTE permission on the conversion procedure matched.
If not allowed, it performs as if the given conversion does not exist
(InvalidOid shall be returned).
The
Simon Riggs wrote:
Investigating how that could come about, it looks like there is some
fairly strange stuff going on here. StandbyRecoverPreparedTransactions()
is never called at all.
I told you so:
http://archives.postgresql.org/message-id/4b260b5e.3010...@enterprisedb.com
On 12/15/2009 9:42 PM, Robert Haas wrote:
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harrimanharri...@acm.org wrote:
Your worry ii) can be ignored, managing to compile on such
compilers is already overachievement.
I think so too. With your opinion added to mine, do we constitute a
consensus of
98 matches
Mail list logo
