Re: [HACKERS] numeric_to_number() function skipping some digits

Hi, On Mon, Sep 21, 2009 at 12:36 PM, Brendan Jurd wrote: > 2009/9/21 Jeevan Chalke : > > 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

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

Gurjeet Singh writes: > ON instead of second ALTER looks better, and IMHO DATABASE should > be optional too: > ALTER ROLE [ON DATABASE ] SET TO ; IN, not ON. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to y

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

On Tue, Sep 22, 2009 at 4:16 AM, Bernd Helmle wrote: > > > --On 21. September 2009 13:42:21 +0200 Bernd Helmle > wrote: > > >> >> --On 20. September 2009 22:56:53 -0400 Robert Haas >> wrote: >> >> So is this ready to commit, or what? >>> >> >> Not yet, see the comments Alvaro did upthread. Ple

Re: [HACKERS] Hot Standby 0.2.1

On Tue, Sep 15, 2009 at 2:41 PM, 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. > > OVERVIEW > > You can download PDF vers

Re: [HACKERS] Using results from INSERT ... RETURNING

On Sun, Sep 6, 2009 at 6:10 AM, Marko Tiikkaja 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 INSERT, UPDATE, and DELETE is not

Re: [HACKERS] Standalone backends run StartupXLOG in an incorrect environment

On Monday 21 September 2009 14:24:07 Tom Lane wrote: > Alvaro Herrera 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

Re: [HACKERS] Hot Standby 0.2.1

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 de

Re: [HACKERS] [PATCH] pgbench: new feature allowing to launch shell commands

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

Re: [HACKERS] updated hstore patch

Andrew Gierth 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 (pgsql-hackers@postgresql

Re: [HACKERS] updated hstore patch

> "Tom" == Tom Lane 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 'explai

Re: [HACKERS] updated hstore patch

"David E. Wheeler" 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 verbose' output is

Re: [HACKERS] updated hstore patch

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' => now()::text),'a')

Re: [HACKERS] updated hstore patch

> "David" == "David E Wheeler" 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 bein

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

On Mon, Sep 21, 2009 at 12:23 PM, Alvaro Herrera 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? > > What feedback is i

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 21. September 2009 13:42:21 +0200 Bernd Helmle wrote: --On 20. September 2009 22:56:53 -0400 Robert Haas 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 (

Re: [HACKERS] Adding \ev view editor?

Tom Lane wrote: Andrew Dunstan 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 anyo

Re: [HACKERS] generic copy options

Tom Lane 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 (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] [rfc] unicode escapes for extended strings

On Wed, 2009-09-09 at 18:26 +0300, Marko Kreen wrote: > Unicode escapes for extended strings. > > On 4/16/09, Marko Kreen 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 stdstr

Re: [HACKERS] Adding \ev view editor?

Andrew Dunstan 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 can make it w

Re: [HACKERS] test_fsync file overrun

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

Re: [HACKERS] generic copy options

Emmanuel Cecchet 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: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Hot Standby 0.2.1

On Mon, Sep 21, 2009 at 9:01 AM, Simon Riggs 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 subscription: http://www.po

Re: [HACKERS] Hot Standby 0.2.1

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 h

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

Alvaro Herrera 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 course, this particular synta

Re: [HACKERS] Adding \ev view editor?

Tom Lane wrote: Andrew Dunstan 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 pret

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

On Mon, Sep 21, 2009 at 3:14 PM, Alvaro Herrera 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 clear, even to an

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

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 onl

[HACKERS] Progress on Writeable CTEs

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 rela

Re: [HACKERS] Adding \ev view editor?

Andrew Dunstan 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 option,

Re: [HACKERS] Adding \ev view editor?

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

Re: [HACKERS] Standalone backends run StartupXLOG in an incorrect environment

Alvaro Herrera 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, > for example when the dat

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

On Mon, Sep 21, 2009 at 1:32 PM, Josh Berkus 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 another

Re: [HACKERS] pg_hba.conf: samehost and samenet [REVIEW]

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 >> [...] >

Re: [HACKERS] Standalone backends run StartupXLOG in an incorrect environment

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 com

Re: [HACKERS] generic copy options

On Mon, Sep 21, 2009 at 1:51 PM, 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"? Good catch, +1. ...Robert -- Sent via pgsql-hackers mailing l

Re: [HACKERS] generic copy options

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 cs

Re: [HACKERS] generic copy options

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

Re: [HACKERS] updated hstore patch

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 h

Re: [HACKERS] updated hstore patch

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 delete(hstore,$

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

>> 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.co

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

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

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

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 f

Re: [HACKERS] generic copy options

Emmanuel Cecchet 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 it is. This way

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

On Mon, Sep 21, 2009 at 12:21 AM, Alvaro Herrera 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 a first look, i

Re: [HACKERS] Resjunk sort columns, Heikki's index-only quals patch, and bug #5000

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 Linna

Re: [HACKERS] WIP: generalized index constraints

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 unl

Re: [HACKERS] Hot Standby 0.2.1

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 th

Re: [HACKERS] Hot Standby 0.2.1

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

Re: [HACKERS] TODO item: Allow more complex user/database default GUC settings

--On 20. September 2009 22:56:53 -0400 Robert Haas 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 the weekend, i'm sorry).

Re: [HACKERS] [PATCH] DefaultACLs

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 j

Re: [HACKERS] Hot Standby 0.2.1

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.

Re: [HACKERS] GRANT ON ALL IN schema

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

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

Jeff Janes írta: > On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan > wrote: > > Boszormenyi Zoltan írta: > > Alvaro Herrera írta: > > > >> Boszormenyi Zoltan wrote: > >> > >> > >> > >>> The vague consensus for syntax options was that the

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

Jeff Janes írta: > On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan > wrote: > > Boszormenyi Zoltan írta: > > > > Okay, we implemented only the lock_timeout GUC. > > Patch attached, hopefully in an acceptable form. > > Documentation included in the pa

Re: [HACKERS] Streaming Replication patch for CommitFest 2009-09

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 submitted.

Re: [HACKERS] Linux LSB init script

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 p

Re: [HACKERS] numeric_to_number() function skipping some digits

2009/9/21 Brendan Jurd : > > # 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: http://www.postgresql.org/mailpref/pgs

Re: [HACKERS] numeric_to_number() function skipping some digits

2009/9/21 Jeevan Chalke : > 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 PG where as it returns '3