2009/9/6 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is an update of largeobject access controls.
it applies fine (just 3 succeded hunks), compiles and passes
regression tests...
ALTER LARGE OBJECT is working, but now that we can change the owner of
a LO we should be able to see who
Hi,
On Sat, Sep 19, 2009 at 1:52 AM, Brendan Jurd dire...@gmail.com wrote:
2009/9/19 Tom Lane t...@sss.pgh.pa.us:
Should we have it throw an error if the input corresponding to a G
symbol doesn't match the expected group separator? I'm concerned that
that would break applications that
2009/9/21 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Oracle returns 19-SEP-09 irrespective of the format.
Here in PG, we have getting the proper date irrespective of the format as
Oracle. But in the case to to_number the returned value is wrong. For
example following query returns '340' on
2009/9/21 Brendan Jurd dire...@gmail.com:
# SELECT regexp_replace('34,50', E'[\\d.]', '', 'g')::numeric;
3450
Sorry, that regex ought to have read E'[^\\d.]'.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
It seems like there is some support for what this patch is trying to
do, but much disagreement about the details of how to get there.
Where do we go from here?
I think the next step would be to outline what changes would be
necessary in
Having gone through the patch now in more detail, I think it's in pretty
good shape. I'm happy with the overall design, except that I haven't
been able to make up my mind if walreceiver should indeed be a
stand-alone program as discussed, or a postmaster child process as in
the patch you
Jeff Janes írta:
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Okay, we implemented only the lock_timeout GUC.
Patch attached, hopefully in an acceptable form.
Documentation included in
Jeff Janes írta:
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
Boszormenyi Zoltan írta:
Alvaro Herrera írta:
Boszormenyi Zoltan wrote:
The vague consensus for syntax options was that the GUC
Abhijit Menon-Sen wrote:
I have not yet been able to do a complete review of this patch, but I am
posting this because I'll be travelling for a week starting tomorrow. My
comments are based mostly on reading the patch, and not on any intensive
testing of the feature. I have left the patch status
Simon Riggs wrote:
OK, here is the latest version of the Hot Standby patchset. This is
about version 30+ by now, but we should regard this as 0.2.1
Patch against CVS HEAD (now): clean apply, compile, no known bugs.
Thanks! Attached is some minor comment and fixes, and some dead code
removal.
Hi,
here's a (late, sorry about that) review:
== Trivia ==
Patch applies cleanly with a few 1 line offsets.
It's unified, not context, but that's trivial.
The patch adds some trailing whitespace, which is not good (git diff
shows it in red, it's easy to spot it). There's also one
hunk that's
--On 20. September 2009 22:56:53 -0400 Robert Haas robertmh...@gmail.com
wrote:
So is this ready to commit, or what?
Not yet, see the comments Alvaro did upthread. Please note that i'm still
reviewing this one and i hope to post results tomorrow (there wasn't plenty
of free time over
On Mon, 2009-09-21 at 13:50 +0300, Heikki Linnakangas wrote:
The only bug I've found
!
is this that we seem to be missing conflict
resolution for GiST index tuples deleted by the kill_prior_tuples
mechanism. Unless I'm missing something, we need similar handling there
that we have in
On Mon, 2009-09-21 at 13:50 +0300, Heikki Linnakangas wrote:
The documentation talks about setting and checking
default_transaction_read_only, but I think it doesn't say anything
about
transaction_read_only, which I find odd. This in particular:
Users will be able to tell whether their
On Sun, 2009-09-20 at 10:08 -0700, Jeff Davis wrote:
On Sun, 2009-09-20 at 13:01 -0400, Tom Lane wrote:
The current infrastructure for deferred uniqueness requires that the
thing actually be a constraint, with an entry in pg_constraint that
can carry the deferrability options. So unless we
Robert Haas wrote:
Since you previously stated that you were going to put this patch
aside to work on HS and SR[1], I'm going to move this to Returned with
Feedback for now. Hope that's OK, and that the feedback is sufficient
and useful.
Yes, on both counts. Thank you!
--
Heikki
On Mon, Sep 21, 2009 at 12:21 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
Here's a first shot on this for my current review round. Patch needed to
re-merged into current CVS HEAD due to some merge conflicts, i've also
adjusted the regression tests (minor). On
Emmanuel Cecchet m...@frogthinker.org writes:
The easiest for both implementation and documentation might just be to
have a matrix of options.
Each option has a row and a column in the matrix. The intersection of a
row and a column is set to 0 if options are not compatible and set to 1
if
Robert Haas escribió:
So here's the followup question - do you intend to do one of those
things for this CommitFest, or should we mark this as Returned with
Feedback once Bernd posts the rest of his review?
What feedback is it supposed to be returned with? Precisely what I
wanted is some
Alvaro Herrera escribió:
What feedback is it supposed to be returned with? Precisely what I
wanted is some feedback on the general idea. Brendan's I like the
approach is good, but is it enough to deter a later veto from someone
else?
s/Brendan/Bernd/
--
Alvaro Herrera
I think that if the use case for a GUC is to set it, run a single very
specific statement, and then unset it, that is pretty clear evidence that
this should not be a GUC in the first place.
+1
Plus, do we really want another GUC?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
On Sep 20, 2009, at 3:14 PM, Andrew Gierth wrote:
I think you're missing the point here; I can't control what it
resolves
to, since that's the job of the function overload resolution code.
Yeah, but I think that the existing behavior is probably the best.
But I checked, and
On Sep 20, 2009, at 12:15 PM, Tom Lane wrote:
That recipe doesn't actually work for cases like this. What *would*
work is loading the module *before* restoring from your old dump,
then relying on the CREATEs from the incoming dump to fail.
Jesus this is hacky, either way. :-(
I believe we
I wrote:
As far as I can tell, the majority opinion is to use format csv
BTW, if we're going to do that, shouldn't the binary option instead
be spelled format binary?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Tom Lane wrote:
I wrote:
As far as I can tell, the majority opinion is to use format csv
BTW, if we're going to do that, shouldn't the binary option instead
be spelled format binary?
Looking at the doc, it looks like FORMAT should be mandatory and be
either text, binary or csv
On Mon, Sep 21, 2009 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
As far as I can tell, the majority opinion is to use format csv
BTW, if we're going to do that, shouldn't the binary option instead
be spelled format binary?
Good catch, +1.
...Robert
--
Sent via pgsql-hackers
Thanks for your review!
Abhijit Menon-Sen wrote:
First, it needs to be reformatted to not use a space before the opening
parentheses in (some) function calls and definitions.
Fixed in the attached patch.
*** a/doc/src/sgml/client-auth.sgml
--- b/doc/src/sgml/client-auth.sgml
[...]
I'd
On Mon, Sep 21, 2009 at 1:32 PM, Josh Berkus j...@agliodbs.com wrote:
I think that if the use case for a GUC is to set it, run a single very
specific statement, and then unset it, that is pretty clear evidence that
this should not be a GUC in the first place.
+1
Plus, do we really want
Alvaro Herrera alvhe...@commandprompt.com writes:
So if you need to enter standalone mode, you'll have to start
postmaster, wait for replay to finish, stop it and restart standalone.
Yeah, that's the case at the moment.
Would this be a problem when you need standalone mode in an emergency,
Tom Lane wrote:
It might be worth pointing out that what I don't want pg_dump doing
is suppressing useless parentheses. Adding whitespace ought to be
safe enough. So if anyone wanted to do the work of decoupling those
two effects of the prettyprint option, we could have semi pretty
printed
Tom Lane wrote:
Fixing this will require rearranging things around InitPostgres
(in particular, I think InitBufferPoolBackend will have to be
called directly from postgres.c). Since that code got rearranged
quite a bit last month, I'd be hesitant to try to back-patch whatever
fix we come up
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
It might be worth pointing out that what I don't want pg_dump doing
is suppressing useless parentheses. Adding whitespace ought to be
safe enough. So if anyone wanted to do the work of decoupling those
two effects of the prettyprint
Hi,
I've looked at implementing writeable CTEs on top of my DML node patch
(repo here: git://git.postgresql.org/git/writeable_cte.git ) and
encountered a few conundrums. You can see what I've done in the
actually_write branch of that repo.
- Currently we only store the OIDs of the result
Robert Haas escribió:
Of course, I don't want:
- GUCs that I'm going to set, execute one statement, and the unset
(and this likely falls into that category).
- GUCs that are poorly designed so that it's not clear, even to an
experienced user, what value to set.
- GUCs that exist only to
On Mon, Sep 21, 2009 at 3:14 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
Of course, I don't want:
- GUCs that I'm going to set, execute one statement, and the unset
(and this likely falls into that category).
- GUCs that are poorly designed so that it's not
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
It might be worth pointing out that what I don't want pg_dump doing
is suppressing useless parentheses. Adding whitespace ought to be
safe enough. So if anyone wanted to do the work of decoupling those
two
Alvaro Herrera alvhe...@commandprompt.com writes:
Perhaps we'd benefit from a way to set a variable for a single query;
Yeah, particularly if it allows us to fend off requests for random
one-off features to accomplish the same thing ...
WITH ( SET query_lock_timeout = 5s ) SELECT ...
Of
On Mon, 2009-09-21 at 14:01 +0100, Simon Riggs wrote:
On Mon, 2009-09-21 at 13:50 +0300, Heikki Linnakangas wrote:
is this that we seem to be missing conflict
resolution for GiST index tuples deleted by the kill_prior_tuples
mechanism. Unless I'm missing something, we need similar
On Mon, Sep 21, 2009 at 9:01 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-09-21 at 13:50 +0300, Heikki Linnakangas wrote:
The only bug I've found
!
Yeah, wow.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Emmanuel Cecchet m...@asterdata.com writes:
[ generic copy options patch ]
Applied with revisions as discussed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Jeff Janes wrote:
test_fsync in tools/fsync pre-creates a 16MB file. If it is given a number
of iterations greater than 1024 (like one might use if trying to see what
happens when NVRAM gets filled, or on a journaling file system), than one of
the writes being timed will have to extend the
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
That's not what I had in mind by decoupling the option's effects.
Well, regardless of that it does what I want, and with a fairly small
amount of code.
Well, yeah, because you are paying no mind to what anyone else might
want.
I
On Wed, 2009-09-09 at 18:26 +0300, Marko Kreen wrote:
Unicode escapes for extended strings.
On 4/16/09, Marko Kreen mark...@gmail.com wrote:
Reasons:
- More people are familiar with \u escaping, as it's standard
in Java/C#/Python, probably more..
- U strings will not work when
Tom Lane t...@sss.pgh.pa.us writes:
Applied with revisions as discussed.
Excellent ;)
Now if you wanted a small option to play with to test the extensibility
of the new system, should I propose DEFAULT '\D' (e.g.)?
Regards,
--
dim
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
That's not what I had in mind by decoupling the option's effects.
Well, regardless of that it does what I want, and with a fairly small
amount of code.
Well, yeah, because you are paying no
--On 21. September 2009 13:42:21 +0200 Bernd Helmle maili...@oopsware.de
wrote:
--On 20. September 2009 22:56:53 -0400 Robert Haas
robertmh...@gmail.com wrote:
So is this ready to commit, or what?
Not yet, see the comments Alvaro did upthread. Please note that i'm still
reviewing this
On Mon, Sep 21, 2009 at 12:23 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
So here's the followup question - do you intend to do one of those
things for this CommitFest, or should we mark this as Returned with
Feedback once Bernd posts the rest of his review?
David == David E Wheeler da...@kineticode.com writes:
But I checked, and delete(hstore,$1) still resolves to
delete(hstore,text) when the type of $1 is not specified, so there's
no compatibility issue there that I can see. (I'm not sure I
understand _why_ it resolves to that rather than
On Sep 21, 2009, at 4:57 PM, Andrew Gierth wrote:
I don't think there's any way to do that from the regression tests.
The output that you demonstrated a few messages back should do nicely
for delete(), at least:
contrib_regression=# explain verbose select delete(('a' =
David E. Wheeler da...@kineticode.com writes:
On Sep 21, 2009, at 4:57 PM, Andrew Gierth wrote:
I don't think there's any way to do that from the regression tests.
The output that you demonstrated a few messages back should do nicely
for delete(), at least:
Anything involving 'explain
Tom == Tom Lane t...@sss.pgh.pa.us writes:
On Sep 21, 2009, at 4:57 PM, Andrew Gierth wrote:
I don't think there's any way to do that from the regression tests.
The output that you demonstrated a few messages back should do nicely
for delete(), at least:
Tom Anything involving
Andrew Gierth and...@tao11.riddles.org.uk writes:
Is delete('...'::hstore,'foo') guaranteed to resolve to the same
function as delete('...'::hstore,$1) where $1 has no type specified?
Yup. They're both UNKNOWN.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hi,
Sorry for my late reply again :o)
You will find my answers on-the-line.
You really should be returning a value at the point since the function
signature defines a return type. If not the function should be void,
which it cannot be in this context since it is used for boolean tests
Simon Riggs wrote:
OK, here is the latest version of the Hot Standby patchset. This is
about version 30+ by now, but we should regard this as 0.2.1
Patch against CVS HEAD (now): clean apply, compile, no known bugs.
Wow, great! Simon has allowed us to pass a great milestone in Postgres
On Monday 21 September 2009 14:24:07 Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
So if you need to enter standalone mode, you'll have to start
postmaster, wait for replay to finish, stop it and restart standalone.
Yeah, that's the case at the moment.
Would this be a
On Sun, Sep 6, 2009 at 6:10 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Fixed a couple of bugs and renovated ExecInitDml() a bit. Patch attached.
Hi, I'm reviewing this patch for this CommitFest.
With regard to the changes in explain.c, I think that the way you've
capitalized
On Tue, Sep 15, 2009 at 2:41 PM, Simon Riggs si...@2ndquadrant.com wrote:
OK, here is the latest version of the Hot Standby patchset. This is
about version 30+ by now, but we should regard this as 0.2.1
Patch against CVS HEAD (now): clean apply, compile, no known bugs.
OVERVIEW
You can
On Tue, Sep 22, 2009 at 4:16 AM, Bernd Helmle maili...@oopsware.de wrote:
--On 21. September 2009 13:42:21 +0200 Bernd Helmle maili...@oopsware.de
wrote:
--On 20. September 2009 22:56:53 -0400 Robert Haas
robertmh...@gmail.com wrote:
So is this ready to commit, or what?
Not yet,
Gurjeet Singh singh.gurj...@gmail.com writes:
ON instead of second ALTER looks better, and IMHO DATABASE dbname should
be optional too:
ALTER ROLE rolename [ON DATABASE dbname] SET config TO value;
IN, not ON.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hi,
On Mon, Sep 21, 2009 at 12:36 PM, Brendan Jurd dire...@gmail.com wrote:
2009/9/21 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Oracle returns 19-SEP-09 irrespective of the format.
Here in PG, we have getting the proper date irrespective of the format as
Oracle. But in the case to
60 matches
Mail list logo
