Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance

--On 16. Juni 2010 14:31:00 +0200 Bernd Helmle wrote: There are some spelling and grammar errors in comments that I can help fix if you want the help. You're welcome. I have pushed my branch to my git repos as well, if you like to start from there:

Re: [HACKERS] antisocial things you can do in git (but not CVS)

* Robert Haas: > 1. Inability to cleanly and easily (and programatically) identify who > committed what. With CVS, the author of a revision is the person who > committed it, period. With git, the author string can be set to > anything the person typing 'git commit' feels like. It's even more di

Re: [HACKERS] Add column if not exists (CINE)

On Fri, Jul 23, 2010 at 2:46 AM, Bernd Helmle wrote: > > > --On 21. Juli 2010 17:16:13 -0400 Robert Haas wrote: > >> I get the same error message from concurrent CREATE TABLE commands >> even without CINE... >> >> S1: >> rhaas=# begin; >> BEGIN >> rhaas=# create table foo (id int); >> CREATE TABL

Re: [HACKERS] Patch for 9.1: initdb -C option

2010/7/23 KaiGai Kohei : > Sorry for the confusion. > > What I wanted to say is the patch itself is fine but we need to make consensus > before the detailed code reviewing. I guess we probably need some more people to express an opinion, then. Do you have one? I'm not sure I do, yet. I'd like to

Re: [HACKERS] security label support, part.2

2010/7/23 KaiGai Kohei : >> Hmm.  How about if there's just one provider loaded, you can omit it, >> but if you fail to specify it and there's>1 loaded, we just throw an >> error saying you didn't specify whose label it is. >> > Perhaps, we need to return the caller a state whether one provider che

Re: [HACKERS] security label support, part.2

* Robert Haas (robertmh...@gmail.com) wrote: > I don't understand why we wouldn't be able to support multiple > providers for row-level security. Why do you think that's a problem? My guess would be that he's concerned about only having space in the tuple header for 1 label. I see two answers- o

Re: [HACKERS] security label support, part.2

On Fri, Jul 23, 2010 at 8:32 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> I don't understand why we wouldn't be able to support multiple >> providers for row-level security.  Why do you think that's a problem? > > My guess would be that he's concerned about only havin

Re: [HACKERS] security label support, part.2

(2010/07/23 20:44), Robert Haas wrote: 2010/7/23 KaiGai Kohei: Hmm. How about if there's just one provider loaded, you can omit it, but if you fail to specify it and there's>1 loaded, we just throw an error saying you didn't specify whose label it is. Perhaps, we need to return the caller a s

Re: [HACKERS] Patch for 9.1: initdb -C option

On Jul 23, 2010, at 6:36 AM, Robert Haas wrote: > 2010/7/23 KaiGai Kohei : >> Sorry for the confusion. >> >> What I wanted to say is the patch itself is fine but we need to make >> consensus >> before the detailed code reviewing. > > I guess we probably need some more people to express an opin

Re: [HACKERS] [JDBC] Trouble with COPY IN

On Thu, 22 Jul 2010, Robert Haas wrote: On Thu, Jul 22, 2010 at 5:34 PM, Kris Jurka wrote: Attached is a patch to make the server continue to consume protocol data until instructed to stop by the client in the same way as copying text data to the server currently works. I guess the obvio

Re: [HACKERS] [JDBC] Trouble with COPY IN

Kris Jurka wrote: I guess the obvious question is whether we shouldn't instead change the docs to match the behavior. I suspect there's almost no chance we'd consider back-patching a change of this type, since it is a clear behavior change. And even if we did, there would still be people runni

Re: [HACKERS] security label support, part.2

On Fri, Jul 23, 2010 at 8:59 AM, KaiGai Kohei wrote: > (2010/07/23 20:44), Robert Haas wrote: >> >> 2010/7/23 KaiGai Kohei: Hmm.  How about if there's just one provider loaded, you can omit it, but if you fail to specify it and there's>1 loaded, we just throw an error saying yo

Re: [HACKERS] [JDBC] Trouble with COPY IN

Kris Jurka writes: > Attached is a patch to make the server continue to consume protocol data > until instructed to stop by the client in the same way as copying text > data to the server currently works. I believe this is a misunderstanding of the protocol spec. The spec is (intended to say t

Re: [HACKERS] Patch for 9.1: initdb -C option

David Christensen escreveu: > Like I said in the original submission, I found it helpful for the > programmatic configuration of a number of simultaneous node, but if it's not > generally useful to the community at large, I'll understand if it's punted. > I'm afraid it is the only use case for t

Re: [HACKERS] [JDBC] Trouble with COPY IN

On Fri, Jul 23, 2010 at 9:32 AM, Andrew Dunstan wrote: > Kris Jurka wrote: >>> >>> I guess the obvious question is whether we shouldn't instead change >>> the docs to match the behavior. I suspect there's almost no chance >>> we'd consider back-patching a change of this type, since it is a clear >

Re: [HACKERS] [JDBC] Trouble with COPY IN

On 7/23/2010 6:40 AM, Tom Lane wrote: Kris Jurka writes: Attached is a patch to make the server continue to consume protocol data until instructed to stop by the client in the same way as copying text data to the server currently works. I believe this is a misunderstanding of the protocol spe

Re: [HACKERS] Patch for 9.1: initdb -C option

David Christensen wrote: > At this point, I have no real preference for this patch; it is > just as easy to echo line >> datadir/postgresql.conf, so perhaps > that makes this patch somewhat pointless. On reflection, I'm inclined to agree. > I suppose there's a shaky argument to be made for W

Re: [HACKERS] [PATCH] "could not reattach to shared memory" on Windows

On Tue, Jul 20, 2010 at 17:31, Etienne Dube wrote: > On 09/02/2010 4:09 PM, Etienne Dube wrote: >> >> Magnus Hagander wrote: >>> >>> IIRC, we've had zero reports on whether the patch worked at all on 8.2 >>> in an environment where the problem actually existed. So yes, some >>> testing and feedbac

Re: [HACKERS] [JDBC] Trouble with COPY IN

Kris Jurka writes: > On 7/23/2010 6:40 AM, Tom Lane wrote: >> I believe this is a misunderstanding of the protocol spec. The spec is >> (intended to say that) we'll continue to accept data after reporting an >> error, not that we will silently swallow an incorrect data stream and >> not complain

Re: [HACKERS] psql \conninfo command (was: Patch: psql \whoami option)

On Wed, Jul 21, 2010 at 11:13 PM, Fujii Masao wrote: > On Thu, Jul 22, 2010 at 11:57 AM, Robert Haas wrote: >> Should we be using is_absolute_path() here instead, as libpq does? > > Yes. The attached patch does that. > >>> On Wed, Jul 21, 2010 at 10:09 PM, David Christensen >>> wrote: >>> If we

Re: [HACKERS] including backend ID in relpath of temp rels - updated patch

On Thu, Jun 10, 2010 at 3:39 PM, Robert Haas wrote: > > > I believe that this patch will clear away one major obstacle to > implementing global temporary and unlogged tables: it enables us to be > sure of cleaning up properly after a crash without relying on catalog > entries or XLOG.  Based on pr

Re: [HACKERS] [RRR] CommitFest 2010-07 week one progress report

Hi, On 07/22/2010 08:51 PM, Robert Haas wrote: It seems to me that the discussion is Alvaro and I are having with Markus is tilted toward having Markus rewrite the imessages interface to use an SLRU, in which case neither of them will go in this CF. I'm hopeful that Heikki or Tom will comment o

Re: [HACKERS] [JDBC] Trouble with COPY IN

On Fri, 23 Jul 2010, Tom Lane wrote: Kris Jurka writes: On 7/23/2010 6:40 AM, Tom Lane wrote: I believe this is a misunderstanding of the protocol spec. The spec is (intended to say that) we'll continue to accept data after reporting an error, not that we will silently swallow an incorrect

Re: [HACKERS] CommitFest 2010-07 week one progress report

Markus Wanner wrote: > On 07/22/2010 08:51 PM, Robert Haas wrote: >> It seems to me that the discussion is Alvaro and I are having >> with Markus is tilted toward having Markus rewrite the imessages >> interface to use an SLRU, in which case neither of them will go >> in this CF. I'm hopeful tha

Re: [HACKERS] Functional dependencies and GROUP BY

On Sun, Jul 18, 2010 at 02:40, Peter Eisentraut wrote: > On lör, 2010-07-17 at 11:13 -0600, Alex Hunsaker wrote: >> So I would expect the more indexes you >> had or group by items to slow it down.  Not so much the number of >> columns.  Right? > > At the outer level (which is not visible in this p

Re: [HACKERS] Functional dependencies and GROUP BY

On Fri, Jul 23, 2010 at 11:00, Alex Hunsaker wrote: > Alternatively we could make it > work with just primary keys until the other patch gets in.  I think > that makes sense, find that attached.  Thoughts? *sigh*, find attached a version that removes talk of unique not null constraints from the d

Re: [HACKERS] multibyte charater set in levenshtein function

Excerpts from Alexander Korotkov's message of jue jul 22 03:21:57 -0400 2010: > On Thu, Jul 22, 2010 at 1:59 AM, Robert Haas wrote: > > > Ah, I see. That's pretty compelling, I guess. Although it still > > seems like a lot of code... > > > I think there is a way to merge single-byte and multi-b

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote: > Hi, > > From the code I understood that when executing a query "normally", > in READ COMMITTED mode, we take a new snapshot for every query that > comes out of rewrite. But in an EXPLAIN ANALYZE, we only update the > CID of the sna

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On 7/23/2010 8:52 PM, David Fetter wrote: On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote: Did I misunderstand the code? And if I didn't, why do we do this differently? You mentioned in IRC that this was in aid of getting wCTEs going. How are these things connected? Currentl

Re: [HACKERS] patch: to_string, to_array functions

Robert Haas writes: so my preferences: 1. split, join - I checked - we are able to create "join" function 2. split, array_join - when only "join" can be a problem 3. string_split, array_join - there are not clean symmetry, but it respect wide used a semantics - string

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Fri, Jul 23, 2010 at 2:18 AM, Joseph Adams wrote: > This is a work-in-progress patch of my GSoC project: Add JSON datatype > to PostgreSQL.  It provides the following: > >  * JSON datatype: A TEXT-like datatype for holding JSON-formatted > text.  Although the JSON RFC decrees that a JSON text b

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Fri, Jul 23, 2010 at 2:34 PM, Robert Haas wrote: > - elog() must be used except for "can't happen" situations.  Compare > the way numeric_in() throws an error message versus json_in(). Er... that should have said "elog() must NOT be used except for can't happen situations". Also, I was just l

[HACKERS] permission inconsistency with functions

Hello, I am writing a blog on backups with postgresql, which I plan at some point (if someone doesn't beat me to it) on turning into a patch for the docs but I found this inconsistency: The docs state that: "In particular, it must have read access to all tables that you want to back up, so in pr

Re: [HACKERS] permission inconsistency with functions

On fre, 2010-07-23 at 11:48 -0700, Joshua D. Drake wrote: > "In particular, it must have read access to all tables that you want > to > back up, so in practice you almost always have to run it as a database > superuser." > > Ignoring the fact that databases have a lot more objects than tables, > t

Re: [HACKERS] review: psql: edit function, show function commands patch

Hello 2010/7/23 Jan Urbański : > On 21/07/10 14:43, Pavel Stehule wrote: >> Hello >> >> I am sending a actualised patch. > > Hi, thanks! > >> I understand to your criticism about line numbering. I have to >> agree. With line numbering the patch is longer. I have a one >> significant reason for it.

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On Fri, Jul 23, 2010 at 2:13 PM, Marko Tiikkaja wrote: > On 7/23/2010 8:52 PM, David Fetter wrote: >> >> On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote: >>> >>> Did I misunderstand the code?  And if I didn't, why do we do this >>> differently? >> >> You mentioned in IRC that this w

Re: [HACKERS] permission inconsistency with functions

On Fri, 2010-07-23 at 21:55 +0300, Peter Eisentraut wrote: > On fre, 2010-07-23 at 11:48 -0700, Joshua D. Drake wrote: > > "In particular, it must have read access to all tables that you want > > to > > back up, so in practice you almost always have to run it as a database > > superuser." > > > >

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On 7/23/2010 10:00 PM, Robert Haas wrote: On Fri, Jul 23, 2010 at 2:13 PM, Marko Tiikkaja wrote: Currently, I'm trying to make wCTEs behave a bit like RULEs do. But if every rewrite product takes a new snapshot, wCTEs will behave very unpredictably. But because EXPLAIN ANALYZE does *not* tak

Re: [HACKERS] patch: to_string, to_array functions

2010/7/23 Dimitri Fontaine : > Robert Haas writes: > so my preferences: > > 1. split, join - I checked - we are able to create "join" function > 2. split, array_join - when only "join" can be a problem > 3. string_split, array_join - there are not clean symmetry, but it > r

[HACKERS] reminder... beta4 is coming

I've just added a couple of recently-reported bugs here: http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items These aren't all 9.0-specific, but we still need to fix them. Also, the steady trickle of 9.0 bug reports that we were getting before seems to have dried up. Does that mean there a

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On 7/23/2010 10:06 PM, I wrote: ProcessQuery() and ExplainOnePlan(). ProcessQuery calls PushActiveSnapshot(GetTransactionSnapshot()) for every statement while ExplainOnePlan calls PushUpdatedSnapshot(GetActiveSnapshot()). Here's a test case demonstrating the difference: =# create table foo(a

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja wrote: > This may be a bit hard to follow, but essentially what happens is that in > EXPLAIN ANALYZE, the INSERT in the rule does not see the changes made by T2 > to baz while in the regular execution scenario it does. Well that's gotta be a bug, bu

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote: > On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja > wrote: > > This may be a bit hard to follow, but essentially what happens is > > that in EXPLAIN ANALYZE, the INSERT in the rule does not see the > > changes made by T2 to baz while in

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On Fri, Jul 23, 2010 at 3:31 PM, David Fetter wrote: > On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote: >> On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja >> wrote: >> > This may be a bit hard to follow, but essentially what happens is >> > that in EXPLAIN ANALYZE, the INSERT in the r

Re: [HACKERS] bg worker: overview

Markus Wanner writes: > Daemon code? That sounds like it could be an addition to the > coordinator, which I'm somewhat hesitant to extend, as it's a pretty > critical process (especially for Postgres-R). [...] > However, note that the coordinator is designed to be just a message > passing or routi

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote: > On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja > wrote: > > This may be a bit hard to follow, but essentially what happens is that in > > EXPLAIN ANALYZE, the INSERT in the rule does not see the changes made by T2 > > to baz while in

Re: [HACKERS] Review: Patch for phypot - Pygmy Hippotause

Tom Lane wrote: > I think the patch is good in principle Since everyone seems to agree this is a good patch which needed minor tweaks, and we haven't heard from the author, I just went ahead and made the changes. Andrew, could you take another look and see if you agree I've covered it all be

[HACKERS] non-overlapping, consecutive partitions

hello everybody, i have just come across some issue which has been bugging me for a while. consider: SELECT * FROM foo ORDER BY bar; if we have an index on bar, we can nicely optimize away the sort step by consulting the index - a btree will return sorted output. under normal circumstan

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On 7/23/2010 10:46 PM, Andres Freund wrote: On Fri, Jul 23, 2010 at 03:30:03PM -0400, Robert Haas wrote: On Fri, Jul 23, 2010 at 3:19 PM, Marko Tiikkaja wrote: This may be a bit hard to follow, but essentially what happens is that in EXPLAIN ANALYZE, the INSERT in the rule does not see the ch

Re: [HACKERS] non-overlapping, consecutive partitions

On 7/23/2010 11:04 PM, Hans-Jürgen Schönig wrote: does anybody see a solution to this problem? what are the main showstoppers to make something like this work? I think we should absolutely make this work when we have a good partitioning implementation. That said, I don't think it's wise to p

Re: [HACKERS] patch: to_string, to_array functions

Hello I am sending a actualised patch. There is only one significant change to last patch. Function to_string was renamed to "implode" and to_array was renamed "explode". Regards Pavel Stehule *** ./doc/src/sgml/func.sgml.orig 2010-07-23 21:18:04.698690857 +0200 --- ./doc/src/sgml/func.sgml 2010

Re: [HACKERS] patch: to_string, to_array functions

Hello Dimitry >> >> I still don't see a compelling reason not to extend existing functions >> with a third argument. Or are we talking about deprecating them in the >> future (like remove their mention in the docs) and have the new names to >> replace them, with the new behavior as the default and

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

Excerpts from Marko Tiikkaja's message of vie jul 23 14:13:18 -0400 2010: > On 7/23/2010 8:52 PM, David Fetter wrote: > > On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote: > >> Did I misunderstand the code? And if I didn't, why do we do this > >> differently? > > > > You mentioned in

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

Alvaro Herrera wrote: > In short I think a wCTE should only advance the CID, not get a > whole new snapshot. Even after unblocking from a write conflict at the READ COMMITTED isolation level? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to yo

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On 7/24/10 12:37 AM +0300, Alvaro Herrera wrote: Excerpts from Marko Tiikkaja's message of vie jul 23 14:13:18 -0400 2010: On 7/23/2010 8:52 PM, David Fetter wrote: On Thu, Jul 22, 2010 at 08:43:35PM +0300, Marko Tiikkaja wrote: Did I misunderstand the code? And if I didn't, why do we do this

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On 7/24/10 12:42 AM +0300, Kevin Grittner wrote: Alvaro Herrera wrote: In short I think a wCTE should only advance the CID, not get a whole new snapshot. Even after unblocking from a write conflict at the READ COMMITTED isolation level? I'm not sure what you mean by this; UPDATE and DELETE

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

Excerpts from Marko Tiikkaja's message of vie jul 23 17:44:21 -0400 2010: > On 7/24/10 12:37 AM +0300, Alvaro Herrera wrote: > > Excerpts from Marko Tiikkaja's message of vie jul 23 14:13:18 -0400 2010: > > I don't think it's fair game to change the behavior of multiple-output > > rules at this po

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On 7/24/10 1:20 AM +0300, Alvaro Herrera wrote: Excerpts from Marko Tiikkaja's message of vie jul 23 17:44:21 -0400 2010: wCTEs are not going to be based on any of the broken behaviour of rules, that's for sure. What I meant is expanding a single query into multiple queries and running the exec

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On 7/24/10 1:20 AM +0300, Alvaro Herrera wrote: It seems like it's EXPLAIN ANALYZE that needs fixing. Yeah, looks like it. I see SQL functions also take a new snapshot for every query. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

On Fri, Jul 23, 2010 at 6:20 PM, Alvaro Herrera wrote: > Excerpts from Marko Tiikkaja's message of vie jul 23 17:44:21 -0400 2010: >> On 7/24/10 12:37 AM +0300, Alvaro Herrera wrote: >> > Excerpts from Marko Tiikkaja's message of vie jul 23 14:13:18 -0400 2010: > >> > I don't think it's fair game

Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

Marko Tiikkaja wrote: > I'm not sure what you mean by this; UPDATE and DELETE can take a > look at the new tuple but that's completely separate from the > snapshot. Never mind -- I remembered that those could operate against tuples not in the original snapshot, but forgot that they did it with

[HACKERS] Review of Synchronous Replication patches

Hello list, My apologies if this email arrives more than once, I've been experiencing troubles posting to the -hackers list and am resending this review as new thread instead of a reply to an existing thread of http://archives.postgresql.org/pgsql-hackers/2010-07/msg01072.php which also has