Re: [HACKERS] Hot Standby 0.2.1

Robert Haas wrote: > On Wed, Sep 16, 2009 at 6:05 PM, Josh Berkus wrote: >> Now that Simon has submitted this, can some of the heavy-hitters here >> review it? Heikki? >> >> Nobody's name is next to it. > > I don't think anyone is planning to ignore this patch, but it wasn't > included in the fi

Re: [HACKERS] Linux LSB init script

On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote: > > what LSB actually entails, which is: > > > > - INFO header > > - standardized exit codes > > - functions from /lib/lsb/init-functions > > As well as a standardized set of actions and standard semantics for > them, if we're only talking

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane wrote: >>> Simon Riggs writes: * Shrink a table concurrently - when no dedicated time available >>> Wishful thinking, which should not stop us from proceeding with the >>> solutions we know how to implement.

Re: [HACKERS] generic copy options

Emmanuel Cecchet writes: > Robert Haas wrote: >>> When we decide to drop the old syntax (in 8.6?), we will be able to clean a >>> lot especially in psql. >> Considering that we are still carrying syntax that was deprecated in >> 7.3, I don't think it's likely that we'll phase out the present synt

Re: [HACKERS] generic copy options

Robert Haas wrote: I don't think the way the doc changes are formatted is consistent with what we've done elsewhere. I think that breaking the options out as a separate block could be OK (because otherwise they have to be duplicated between COPY TO and COPY FROM) but it should be done more like

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Jeff Davis writes: > On Wed, 2009-09-16 at 21:48 -0400, Tom Lane wrote: >> Yeah, I was just wondering about that myself. Seems like there would >> be lots of situations where short exclusive-lock intervals could be >> tolerated, even though not long ones. > But a short-lived exclusive lock can t

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 21:48 -0400, Tom Lane wrote: > Yeah, I was just wondering about that myself. Seems like there would > be lots of situations where short exclusive-lock intervals could be > tolerated, even though not long ones. But a short-lived exclusive lock can turn into a long-lived exclu

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Robert Haas writes: > On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane wrote: >> Simon Riggs writes: >>> * Shrink a table concurrently - when no dedicated time available >> >> Wishful thinking, which should not stop us from proceeding with the >> solutions we know how to implement. > The UPDATE-style

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane wrote: > Simon Riggs writes: >> The way I read the thread so far is that there are multiple >> requirements: > >> * Shrink a table efficiently - when time and space available to do so > > To be addressed by the CLUSTER-based solution (VACUUM REWRITE or >

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Simon Riggs writes: > The way I read the thread so far is that there are multiple > requirements: > * Shrink a table efficiently - when time and space available to do so To be addressed by the CLUSTER-based solution (VACUUM REWRITE or whatever we call it). > * Shrink a table in place - when no

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Simon Riggs writes: > I think it would be useful to have an additional option to force VACUUM > to wait for the lock so it can truncate. It's annoying to have to re-run > VACUUM just to give it a chance at the lock again. It would be better to separate out the truncate-what-you-can behavior as an

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 21:00 -0400, Tom Lane wrote: > But if > we get rid of old-style VACUUM FULL then we do need something to cover > those few-and-far-between situations where you really do desperately > need to compact a table in place; and a utility like this seems like a > reasonable solutio

Re: [HACKERS] Issues for named/mixed function notation patch

On Tue, Sep 15, 2009 at 4:51 AM, Pavel Stehule wrote: >> >> Same problem.  Build log attached. >> >> ...Robert >> > > My renonc, please, try new patch. I forgot mark regproc.c file. > > regards > Pavel Stehule This one compiles for me. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-ha

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Simon Riggs writes: > What we need is VACUUM FULL CONCURRENTLY and REINDEX CONCURRENTLY. VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were possible doesn't make it so. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 20:36 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > For the kicks, I looked at what it would take to write a utility like > > that. It turns out to be quite trivial, patch attached. > > I don't think you've really thought this through; particularly not this: > >

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

>Well, Andrew McNamara just posted today: >http://archives.postgresql.org/message-id/20090916063341.0735c5ac...@longblack.object-craft.com.au > >Had VACUUM FULL not been available, though, I'm pretty sure he would've >come up with something else instead. Indeed I would have. And it was our own sla

Re: [HACKERS] generic copy options

On Wed, Sep 16, 2009 at 6:43 PM, Emmanuel Cecchet wrote: > Here is a new version of the patch with an updated doc and psql. Thanks, that's great. I don't think the way the doc changes are formatted is consistent with what we've done elsewhere. I think that breaking the options out as a separate

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 11:40 -0700, Jeff Davis wrote: > Another thing to think about is that lazy vacuum only shrinks the heap > file if it happens to be able to acquire an access exclusive lock. > Because vacuum can't be run inside a transaction block, I don't think > there's currently a way to e

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote: > I was just going to post that we should make a decision about this, > because ISTM there's some code in Simon's hot standby patch that is only > required to support VACUUM FULL. If we make the decision that we drop > VACUUM FULL in 8.

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Heikki Linnakangas writes: > I'm in favor of removing VACUUM FULL in 8.5. To replace it, we should offer: > 1) VACUUM REWRITE, which is like CLUSTER but doesn't use an index, and Check, although I'm not eager to make REWRITE a fully reserved word, which is what this would entail. I would propos

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

Hi all, Sorry for my late reply. There is no other update for this patch since the 13th of August, at least until today. The new patch is attached By the way I worked on the comments that Dan and Gabriel pointed out. I added a check on system such as to prevent an error from this side. By the way,

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Heikki Linnakangas writes: > For the kicks, I looked at what it would take to write a utility like > that. It turns out to be quite trivial, patch attached. I don't think you've really thought this through; particularly not this: > + rel = heap_open(relid, AccessShareLock); You can NOT modi

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

Josh Berkus writes: > 3. This patch eliminates a common plpgsql beginner error With respect, that argument is one hundred percent false. I can think of maybe two complaints about the behavior that we've heard in the last ten years. The only real argument I've heard in favor of this is that it w

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Robert Haas wrote: > Heikki Linnakangas wrote: >> Hannu Krosing wrote: >>> On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote: 2) Another utility that does something like UPDATE ... WHERE ctid > ? to > I also wonder whether we should consider teaching regular VACUUM to do > a little

Re: [HACKERS] Hot Standby 0.2.1

On Wed, Sep 16, 2009 at 6:05 PM, Josh Berkus wrote: > Now that Simon has submitted this, can some of the heavy-hitters here > review it?  Heikki? > > Nobody's name is next to it. I don't think anyone is planning to ignore this patch, but it wasn't included in the first round of round-robin review

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Robert Haas wrote: > I think this should be in core, not a contrib module. +1 > I also wonder whether we should consider teaching regular VACUUM to > do a little of this every time it's run. Right now, once your table > gets bloated, it stays bloated forever, until you intervene. Making >

Re: [HACKERS] generic copy options

Robert, Here is a new version of the patch with an updated doc and psql. I changed the name of the CSV options to prefix them with csv_ to avoid confusion with any future options. I also had to change the grammar to allow '*' as a parameter (needed for cvs_force_quote). When we decide to drop

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, Sep 16, 2009 at 1:42 PM, Josh Berkus wrote: > On 9/16/09 11:20 AM, Kevin Grittner wrote: >> Josh Berkus wrote: >> >>> a) To date, I have yet to hear a single person bring up an actual >>> real-life use-case where VACUUM FULL was desireable and REWRITE >>> would not be. >> >> Would rewrite

Re: [HACKERS] Hot Standby 0.2.1

All, Now that Simon has submitted this, can some of the heavy-hitters here review it? Heikki? Nobody's name is next to it. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

Josh Berkus wrote: Michael, Have an example at hand? I'd argue that in a case of a function of more complexity from a code clarity standpoint you'd want to assign to a new variable that describes what the new value reflects. Depends on what programming language you're used to. For

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, Sep 16, 2009 at 4:53 PM, Heikki Linnakangas wrote: > Hannu Krosing wrote: >> On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote: >>> 2) Another utility that does something like UPDATE ... WHERE ctid > ? to >>> move tuples to lower pages. It will be different from current VACUUM >>

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

Michael, > Have an example at hand? I'd argue that in a case of a function of more > complexity from a code clarity standpoint you'd want to assign to a new > variable that describes what the new value reflects. Depends on what programming language you're used to. For those of us who do a lot of

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 23:53 +0300, Heikki Linnakangas wrote: > For the kicks, I looked at what it would take to write a utility like > that. It turns out to be quite trivial, patch attached. It uses the same > principle as VACUUM FULL, scans from the end, moving tuples to > lower-numbered pages unt

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 23:53 +0300, Heikki Linnakangas wrote: > Hannu Krosing wrote: > > On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote: > >> 2) Another utility that does something like UPDATE ... WHERE ctid > ? to > >> move tuples to lower pages. It will be different from current VACUU

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hannu Krosing wrote: > On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote: >> 2) Another utility that does something like UPDATE ... WHERE ctid > ? to >> move tuples to lower pages. It will be different from current VACUUM >> FULL in some ways. It won't require a table lock, for example, b

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

On Sep 16, 2009, at 12:44 PM, Michael Glaesemann wrote: Certainly. I was doing that to have a simple example; obviously you wouldn't write a mod funciton, and you wouldn't do it in plpgsql. There are other case where the lack of mutability in IN parameters causes you to create a throwaway

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

On Sep 16, 2009, at 15:17 , Josh Berkus wrote: Michael, This is also currently valid: CREATE FUNCTION mod (x int, y int) RETURNS int LANGUAGE plpgsql AS $f$ DECLARE z INT := x % y; BEGIN RETURN z; END; $f$ As is this: CREATE FUNCTION mod (x int, y int) RETURNS int LANGUAGE plpgsql AS $f$

Re: [HACKERS] WIP: generalized index constraints

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Sep 16, 2009 at 09:45:52AM -0700, Jeff Davis wrote: > On Wed, 2009-09-16 at 15:11 +0200, to...@tuxteam.de wrote: > > One question: does the operator have to be reflexive? I.e. "A op A holds > > for all A"? > > I don't think that reflexivity is

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

Michael, > This is also currently valid: > > CREATE FUNCTION mod (x int, y int) > RETURNS int LANGUAGE plpgsql > AS $f$ > DECLARE > z INT := x % y; > BEGIN > RETURN z; > END; $f$ > > As is this: > > CREATE FUNCTION mod (x int, y int) > RETURNS int LANGUAGE plpgsql > AS $f$ > BEGIN > RETURN

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hannu, > If it is a sequence of > > 1. ordinary VACUUM (it can't run out of FSM anymore, no?) > 2. a process moving live tuples from end (using reverse seqscan) to free > space found scanning in first-to-last direction, either one tuple at a > time or one page at a time, until the two scans meet

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 11:48 -0700, Josh Berkus wrote: > Hannu, > > > The only case is when you are out of disk space and can't afford to > > write out a full set of live rows. > > Well, it's actually rather specific. You need to have: > > a) *Some* free disk space (FULL requires extra disk) but

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 13:20 -0500, Kevin Grittner wrote: > Josh Berkus wrote: > > > a) To date, I have yet to hear a single person bring up an actual > > real-life use-case where VACUUM FULL was desireable and REWRITE > > would not be. > > Would rewrite have handled this?: > > http://archive

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 11:10 -0700, Josh Berkus wrote: > Hackers, > > Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE: > http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959 > > Of note: > > a) To date, I have yet to hear a single person brin

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hannu, > The only case is when you are out of disk space and can't afford to > write out a full set of live rows. Well, it's actually rather specific. You need to have: a) *Some* free disk space (FULL requires extra disk) but not enough to copy one entire table and its indexes. b) be already d

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote: > I was just going to post that we should make a decision about this, > because ISTM there's some code in Simon's hot standby patch that is only > required to support VACUUM FULL. If we make the decision that we drop > VACUUM FULL in 8.5

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 11:10 -0700, Josh Berkus wrote: > Hackers, > > Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE: > http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959 > > Of note: > > a) To date, I have yet to hear a single person brin

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On 9/16/09 11:20 AM, Kevin Grittner wrote: > Josh Berkus wrote: > >> a) To date, I have yet to hear a single person bring up an actual >> real-life use-case where VACUUM FULL was desireable and REWRITE >> would not be. > > Would rewrite have handled this?: > > http://archives.postgresql.org/

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote: > 2) Another utility that does something like UPDATE ... WHERE ctid > ? to > move tuples to lower pages. It will be different from current VACUUM > FULL in some ways. It won't require a table lock, for example, but it > won't be able to m

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

On Sep 16, 2009, at 13:40 , Josh Berkus wrote: 3. This patch eliminates a common plpgsql beginner error and saves all of us heavy plpgsql users some typing, especially when the use of a mutable variable means that we can eliminate the DECLARE section entirely, as in: This: CREATE PROCEDURE mo

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Josh Berkus wrote: > Hackers, > > Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE: > http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959 > > Of note: > > a) To date, I have yet to hear a single person bring up an actual > real-life use-case

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Josh Berkus wrote: > a) To date, I have yet to hear a single person bring up an actual > real-life use-case where VACUUM FULL was desireable and REWRITE > would not be. Would rewrite have handled this?: http://archives.postgresql.org/pgsql-hackers/2009-09/msg01016.php -Kevin -- Sent via

[HACKERS] Feedback on getting rid of VACUUM FULL

Hackers, Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE: http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959 Of note: a) To date, I have yet to hear a single person bring up an actual real-life use-case where VACUUM FULL was desireable and

Re: [HACKERS] WIP: generalized index constraints

On Wed, Sep 16, 2009 at 3:14 AM, Peter Eisentraut wrote: > On Tue, 2009-09-15 at 12:37 -0400, Robert Haas wrote: >> Instead of calling these generalized index constraints, I wonder if we >> oughtn't to be calling them something like "don't-overlap constraints" >> (that's a bad name, but something

Re: [HACKERS] WIP: generalized index constraints

On Tue, 2009-09-15 at 22:52 +1000, Brendan Jurd wrote: > I'm just getting started reviewing this version now. I noticed that > your patch seems to have been generated by git. Ok, I now have a public git repo on git.postgresql.org, and I rebased my patch before I pushed it. See updates in my "gen

Re: [HACKERS] WIP: generalized index constraints

On Wed, 2009-09-16 at 10:14 +0300, Peter Eisentraut wrote: > What they should be called is generalized unique constraints, without > reference to "index". Because what they generalize is the operator by > which uniqueness is determined. How about GUC, for short? ;-) Do you think that Tomás's su

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

> IIRC the original complaint was from someone trying to migrate code > from T/SQL or some other not-quite-PLSQL language. Like you, I'm on > the fence about whether to accept this patch, but it does have some > in-migration rationale. As someone who writes a lot of plpgsql, I'm in favor of the

Re: [HACKERS] Linux LSB init script

Peter Eisentraut wrote: > OK, I have a number of comments on this proposal. Thanks for looking at it. > What does it buy us, in general, and compared to the existing > (non-LSB) script? A conforming script for use in LSB conforming implementations. > what LSB actually entails, which is:

Re: [HACKERS] WIP: generalized index constraints

On Wed, 2009-09-16 at 15:11 +0200, to...@tuxteam.de wrote: > One question: does the operator have to be reflexive? I.e. "A op A holds > for all A"? I don't think that reflexivity is a strict requirement. You could make this a constraint over a boolean attribute such that false conflicts with true

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

On Sep 16, 2009, at 8:49 AM, Merlin Moncure wrote: On Wed, Sep 16, 2009 at 8:59 AM, Robert Haas wrote: At worst it's an upward-compatible extension, or am I wrong? If it's useful, which I think it is, what's the harm? are we guarding against cases like: select _foo, adjust_foo(_foo) from ba

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

On Wed, Sep 16, 2009 at 8:59 AM, Robert Haas wrote: > On Sep 16, 2009, at 8:37 AM, Andrew Dunstan wrote: > >> >> >> Abhijit Menon-Sen wrote: >>> >>> At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote: >>> This patch changes plpgsql IN parameters so they are mutable. >>> >>> Makes se

Re: [HACKERS] Linux LSB init script

OK, I have a number of comments on this proposal. What does it buy us, in general, and compared to the existing (non-LSB) script? This becomes clearer when you consider what LSB actually entails, which is: - INFO header - standardized exit codes - functions from /lib/lsb/init-functions My argum

Re: [HACKERS] WIP: generalized index constraints

On Tue, Sep 15, 2009 at 7:02 PM, Joshua Tolley wrote: > On Tue, Sep 15, 2009 at 05:52:35PM -0400, Tom Lane wrote: >> Jeff Davis writes: >> > On Tue, 2009-09-15 at 14:42 -0700, Jeff Davis wrote: >> >> operator constraints >> >> operator exclusion constraints >> >> operator conflict constraints >>

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

On Sep 16, 2009, at 6:03 AM, Andrew Dunstan wrote: Abhijit Menon-Sen wrote: At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote: How does this compare with PLSQL? I don't remember anything of PL/SQL myself, but Pavel Stehule had this to say in response to the original post: This behav

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

>> > > I'm not terribly impressed by either of Pavel's arguments. SQL/PSM is > irrelevant, and the existence of one inconsistency doesn't seems to me to be > a good rationale to create another. If there were a major increase in > utility I would be more willing, but at best this overcomes a minor >

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

Andrew Dunstan writes: > It probably won't cause any problem with code being migrated from PLSQL, > but it will affect code going the other way. The question is: do we care > about that? I'm prepared to be persuaded that we shouldn't care, but I'm > not quite there yet. IIRC the original compl

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

Andrew Dunstan wrote: > It probably won't cause any problem with code being migrated from > PLSQL, but it will affect code going the other way. The question is: > do we care about that? I'm prepared to be persuaded that we > shouldn't care, but I'm not quite there yet. Anybody trying to port code

Re: [HACKERS] errcontext support in PL/Perl

Selena Deckelmann escribió: > From the patch review group this evening, courtesy of Webb Sprague and > Brent Dombrowski. I'm replying on their behalf so that this response > is in the correct thread. > > Looks like Peter also reviewed, but I'm forwarding this on anyway. > > (Note: Problem runnin

Re: [HACKERS] WIP: generalized index constraints

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Sep 15, 2009 at 10:28:28AM -0700, Jeff Davis wrote: > On Tue, 2009-09-15 at 13:16 -0400, Robert Haas wrote: > > Uhh so what happens if I create an index constraint using the > > +(integer, integer) operator? > > You can use any operator th

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

Abhijit Menon-Sen wrote: At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote: How does this compare with PLSQL? I don't remember anything of PL/SQL myself, but Pavel Stehule had this to say in response to the original post: This behave is in conflict with PL/SQL, what should

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

On Sep 16, 2009, at 8:37 AM, Andrew Dunstan wrote: Abhijit Menon-Sen wrote: At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote: This patch changes plpgsql IN parameters so they are mutable. Makes sense, applies fine, works fine. How does this compare with PLSQL? I know in Ada a

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

Stef Walter wrote: > [Looks like my response to this never made it to the mailing list, > sending again...] Your original message did not carry a Message-Id header, and neither does this one (at least the copy I got). Are you doing something weird to the message? This worries me, because we inte

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote: > > How does this compare with PLSQL? I don't remember anything of PL/SQL myself, but Pavel Stehule had this to say in response to the original post: > This behave is in conflict with PL/SQL, what should do some problems. > I thing, so I un

Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]

Abhijit Menon-Sen wrote: At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote: This patch changes plpgsql IN parameters so they are mutable. Makes sense, applies fine, works fine. How does this compare with PLSQL? I know in Ada an IN argument is in effect a constant. I unde

Re: [HACKERS] Rough draft: easier translation of psql help

On Sun, 2009-09-13 at 23:46 -0400, Alvaro Herrera wrote: > Should create_help.pl be run on "make dist"? It is. -- 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] Streaming Replication patch for CommitFest 2009-09

Hi, On Wed, Sep 16, 2009 at 11:37 AM, Fujii Masao wrote: > I was thinking that the automatic reconnection capability is the TODO item > for the later CF. The infrastructure for it has already been introduced in the > current patch. Please see the macro MAX_WALRCV_RETRIES (backend/ > postmaster/wa

Re: [HACKERS] Bulk Inserts

OK, that makes sense. I thought you had hacked either XLogInsert or the heap WAL replay code so that you could just accumulate tuples in the rdata chain and then submit them all under the cover of a single WALInsertLock. Ah, no, I did not do that. This would be difficult to do : rdata cha

Re: [HACKERS] Hot Standby 0.2.1

--On 15. September 2009 22:41:59 +0100 Simon Riggs wrote: http://wiki.postgresql.org/images/0/01/Hot_Standby_Recovery_Functions.pdf This doesn't work for me, it seems the correct link is ? -- Thanks B

Re: [HACKERS] WIP: generalized index constraints

On Tue, 2009-09-15 at 12:22 -0700, Jeff Davis wrote: > I don't like using the word "unique" in the description, I think it > only > adds to the confusion. It would emphasize that a unique constraint is a common special case of the feature. -- Sent via pgsql-hackers mailing list (pgsql-hackers@p

Re: [HACKERS] WIP: generalized index constraints

On Tue, 2009-09-15 at 12:37 -0400, Robert Haas wrote: > Instead of calling these generalized index constraints, I wonder if we > oughtn't to be calling them something like "don't-overlap constraints" > (that's a bad name, but something along those lines). They're not > really general at all, excep