Re: [HACKERS] typedefs for indent

Bruce Momjian writes: > Frankly, I don't remember anyone complaining we didn't find any typedefs > in pgindent, There are lots and lots of places where it's obvious that pgindent was misinformed on the subject, because it puts in a space where there should not be one, eg "typename * ptr" instead

Re: [HACKERS] 8.4 release notes proof reading 1/2

On Fri, Mar 27, 2009 at 2:44 AM, Bruce Momjian wrote: > Guillaume Smet wrote: >> - "Add -M (query mode) to /contrib/pgbench (ITAGAKI Takahiro)" >> ->Itagaki san's name inconsistent with other mentions of his name > > Above all fixed, thanks. I think you fixed this one the wrong way. It should be

Re: [HACKERS] 8.4 open items list

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas wrote: > That includes a whole slough of patches that weren't submitted until > after November 1st and which I think should probably be bumped en > masse to 8.5: > > postgresql.conf: patch to have ParseConfigFile report all parsing > errors, then bail

Re: [HACKERS] 8.4 open items list

Robert Haas writes: > On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian wrote: >> I think pushing "pre-existing bugs" to 8.5 is a mistake, > What is the threshold for "has to be fixed before we can go to beta" > versus "has to be fixed before release"? I did not by any means intend that those thi

Re: [HACKERS] typedefs for indent

Andrew Dunstan wrote: > >> Andrew, this is disappointing news. When you talked about generating an > >> typedef list from the buildfarm, you were saying how great it would be > >> --- now a year later you post: > >> > >>It'd be nice to get that dealt with before we run pg_indent, but it's > >>

Re: [HACKERS] tuplestore API problem

2009/3/27 Tom Lane : > By chance I discovered that this query in the regression tests > > SELECT ntile(NULL) OVER (ORDER BY ten, four), ten, four FROM tenk1 LIMIT 2; > > stops working if work_mem is small enough: it either dumps core or > delivers wrong answers depending on platform. > > After some

Re: [HACKERS] typedefs for indent

Bruce Momjian wrote: bruce wrote: Andrew Dunstan wrote: This URL gives a typedef list that is (currently) the combined result from three fairly different buildfarm members: dungbeetle | 2009-03-22 06:44:01 brown_bat | 2009-03-21 13:0

Re: [HACKERS] New trigger option of pg_standby

Hi, On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet wrote: > Hi Simon. > > On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs wrote: >> Earlier, we discussed having a single trigger file that contains an >> option rather than two distinct trigger files. That design is better >> because it allows the

Re: [HACKERS] typedefs for indent

bruce wrote: > Andrew Dunstan wrote: > > This URL gives a > > typedef list that is (currently) the combined result from three fairly > > different buildfarm members: > > > > dungbeetle | 2009-03-22 06:44:01 > > brown_bat | 2009-03-21 13:00:58 > >

Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?

laser wrote: > hi all, > > I read the code that it seems easy for the cursor in plpgsql to return > ROW_COUNT after > MOVE LAST etc. The SPI_processed variable already there, but didn't put > it into estate > structure, any reason for that? > > thanks and best regards Sorry, we have decide

Re: [HACKERS] 8.4 release notes proof reading 1/2

Greg Stark wrote: > On Fri, Mar 27, 2009 at 1:44 AM, Bruce Momjian wrote: > > > >> - "Previously EXPLAIN VERBOSE output an internal representation of the > >> query plan" -> s/output/outputs/ ? > > > > The existing wording seems correct. > > I think Bruce's phrasing was in the past tense. It's a

Re: [HACKERS] typedefs for indent

Andrew Dunstan wrote: > This URL gives a > typedef list that is (currently) the combined result from three fairly > different buildfarm members: > > dungbeetle | 2009-03-22 06:44:01 > brown_bat | 2009-03-21 13:00:58 > dawn_bat | 2009-03-21 14:23:4

Re: [HACKERS] 8.4 release notes proof reading 1/2

On Fri, Mar 27, 2009 at 1:44 AM, Bruce Momjian wrote: > >> - "Previously EXPLAIN VERBOSE output an internal representation of the >> query plan" -> s/output/outputs/ ? > > The existing wording seems correct. I think Bruce's phrasing was in the past tense. It's a bit weird because the verb form of

Re: [HACKERS] 8.4 open items list

Robert Haas wrote: > On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian wrote: > >> I'm sure they will. ?But the current problem is getting beta released > >> in the first place, and AFAICS we're all waiting for you. > > > > As Tom said, it is more the open items that we are waiting on, not the > > re

Re: [HACKERS] 8.4 open items list

On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian wrote: >> I'm sure they will.  But the current problem is getting beta released >> in the first place, and AFAICS we're all waiting for you. > > As Tom said, it is more the open items that we are waiting on, not the > release notes, but if if you are

Re: [HACKERS] small but useful patches for text search

On Thu, Mar 26, 2009 at 8:30 PM, Bruce Momjian wrote: > Tom Lane wrote: >> Robert Haas writes: >> > OK, I am all wet.  I now understand why the editing is the >> > time-consuming part of this job.  On the plus side it is probably >> > possible to parallelize it to some degree by splitting the lis

Re: [HACKERS] 8.4 release notes proof reading 1/2

Guillaume Smet wrote: > Bruce, > > Here is the second set of comments: > > - pg_hba.conf: it seems to me the format has changed which may break > existing pg_hba.conf (it broke the default one of the RPM packaging). > We should make it very visible as the format hasn't changed for a > while. I su

Re: [HACKERS] small but useful patches for text search

On Thu, Mar 26, 2009 at 9:28 PM, Bruce Momjian wrote: >> At this point I think we are just trying to get a list of items that >> need to be done before we can release beta.  Very little, if anything, >> should be getting added to that list at this point. > > You can say that, but things are going

Re: [HACKERS] 8.4 release notes proof reading 1/2

Guillaume Smet wrote: > Hi, > > Just to warn people that I'm making a comprehensive proof reading of > the release notes. > > Here are the first comments: > > - "This was available previously via a configure > --enable-integer-datetimes (Neil Conway)" -> I don't think we need > Neil's name in th

Re: [HACKERS] small but useful patches for text search

Robert Haas wrote: > On Thu, Mar 26, 2009 at 8:30 PM, Bruce Momjian wrote: > > Tom Lane wrote: > >> Robert Haas writes: > >> > OK, I am all wet. ?I now understand why the editing is the > >> > time-consuming part of this job. ?On the plus side it is probably > >> > possible to parallelize it to s

Re: [HACKERS] small but useful patches for text search

On Thu, Mar 26, 2009 at 9:35 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Thu, Mar 26, 2009 at 8:31 PM, Bruce Momjian wrote: >> > Josh Berkus wrote: >> >> All, >> >> >> >> > In any case, the release notes aren't normally a bottleneck. ?I still >> >> > think that Bruce had his priorities ou

Re: [HACKERS] small but useful patches for text search

Robert Haas wrote: > On Thu, Mar 26, 2009 at 9:28 PM, Bruce Momjian wrote: > >> At this point I think we are just trying to get a list of items that > >> need to be done before we can release beta. ?Very little, if anything, > >> should be getting added to that list at this point. > > > > You can

Re: [HACKERS] small but useful patches for text search

Robert Haas wrote: > On Thu, Mar 26, 2009 at 8:31 PM, Bruce Momjian wrote: > > Josh Berkus wrote: > >> All, > >> > >> > In any case, the release notes aren't normally a bottleneck. ?I still > >> > think that Bruce had his priorities out of whack in not cleaning up > >> > his open-items list before

[HACKERS] psql: Make tab completion work for ANALYZE VERBOSE ...

Quick patch to fix the fact that the EXPLAIN ANALYZE VERBOSE is clobbering tab-completion for ANALYZE VERBOSE. -- Greg Sabino Mullane g...@endpoint.com End Point Corporation PGP Key: 0x14964AC8 Index: tab-complete.c === RCS file: /pr

Re: [HACKERS] small but useful patches for text search

Robert Haas wrote: > On Thu, Mar 26, 2009 at 8:31 PM, Bruce Momjian wrote: > > Josh Berkus wrote: > >> All, > >> > >> > In any case, the release notes aren't normally a bottleneck. ?I still > >> > think that Bruce had his priorities out of whack in not cleaning up > >> > his open-items list before

Re: [HACKERS] small but useful patches for text search

On Thu, Mar 26, 2009 at 8:31 PM, Bruce Momjian wrote: > Josh Berkus wrote: >> All, >> >> > In any case, the release notes aren't normally a bottleneck.  I still >> > think that Bruce had his priorities out of whack in not cleaning up >> > his open-items list before doing this.  If he had done so,

[HACKERS] Proper subject lines (was: small but useful patches for text search)

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > In any case, the release notes aren't normally a bottleneck. ... Could I respectfully request people make an effort to change the subject lines when the thread radically moves away from its original purpose? Modern mail systems don't thread b

Re: [HACKERS] SSL over Unix-domain sockets

Peter Eisentraut wrote: > Bruce Momjian wrote: > > I thought the logical solution to this was to place the socket in a > > secure directory and not bother with SSL at all. > > How would a client algorithmically determine whether the server socket > was in a "secure" directory? You have to config

Re: [HACKERS] small but useful patches for text search

Tom Lane wrote: > Josh Berkus writes: > > Yes, although Bruce *has* asked for help in cleaning up the open-items list. > > I spent several hours on that on Saturday, and more or less got the bird > in response... the way Bruce has that page set up, only he can do any > actual item removal, the re

Re: [HACKERS] small but useful patches for text search

Josh Berkus wrote: > All, > > > In any case, the release notes aren't normally a bottleneck. I still > > think that Bruce had his priorities out of whack in not cleaning up > > his open-items list before doing this. If he had done so, nobody > > would have noticed how long the notes took. > > Y

Re: [HACKERS] small but useful patches for text search

Tom Lane wrote: > Robert Haas writes: > > OK, I am all wet. I now understand why the editing is the > > time-consuming part of this job. On the plus side it is probably > > possible to parallelize it to some degree by splitting the list into N > > pieces after the "remove insignificant items" st

Re: [HACKERS] small but useful patches for text search

Robert Haas wrote: > OK, I am all wet. I now understand why the editing is the > time-consuming part of this job. On the plus side it is probably > possible to parallelize it to some degree by splitting the list into N > pieces after the "remove insignificant items" step. > > With respect to thi

[HACKERS] Error message and infinite date and timestamp conversion in XML

map_sql_value_to_xml_value() currently errors out with a more or less vague error message, when a date or timestamp datatype with an infinite value is converted to XML. This is likely to create some confusion, especially when you have to debug some complex procedures and involved XML conversio

Re: [HACKERS] maintenance_work_mem and autovacuum

On 3/26/09 4:10 PM, Tom Lane wrote: Simon Riggs writes: On Thu, 2009-03-26 at 13:43 -0700, Josh Berkus wrote: That said, it would be unnecessary if I could use ROLES to set parameters more reliably Hmmm, perhaps the right way to do this is to have a user called "autovacuum" that is use

Re: [HACKERS] maintenance_work_mem and autovacuum

Simon Riggs writes: > On Thu, 2009-03-26 at 13:43 -0700, Josh Berkus wrote: >> That said, it would be unnecessary if I could use ROLES to set >> parameters more reliably > Hmmm, perhaps the right way to do this is to have a user called > "autovacuum" that is used to perform autovacuums. I

Re: [HACKERS] Review: B-Tree emulation for GIN

Jeff Davis writes: > Also, if extractQuery is non-strict, shouldn't we call it and see if it > returns some useful keys? Perhaps. One risk factor for approaching it that way is that there are probably a lot of opclasses out there that haven't bothered to mark these functions strict, since it's n

Re: [HACKERS] "maxretries" option of pg_standby doesn't work as expected

Fujii Masao writes: >> Set the maximum number of times to retry the copy or link command > maxretries option of pg_standby is documented as above, but actually > indicates the maximum number of times to *try* the copy or link command. > So, if "-r 0" is specified, pg_standby always fails. > Atta

Re: [HACKERS] Review: B-Tree emulation for GIN

On Wed, 2009-03-25 at 19:31 -0400, Tom Lane wrote: > * I'd also like to come to some agreement about getting rid of the > fail-on-NULL-scankey problem in newScanKey(). As I noted in the > comment there, we could make that work cleanly if we are willing to > assume that all GIN-indexable operators

Re: [HACKERS] gettext, plural form and translation

On Saturday 21 March 2009 01:01:57 Sergey Burladyan wrote: > Alvaro Herrera writes: > > Care to submit a patch? > > this is it, i divide it into two, first is change source and second is > change ru.po file for psql. I have now committed a more extensive pluralization, but your case is included

Re: [HACKERS] Partitioning feature ...

Hi Kedar, First of all, congratulations for the excellent work. I have some comments and questions. In get_relevent_partition (btw, relevant is spelled with an a) you are maintaining 2 lists. I guess this is only useful for multi-column partitions, right? If you have a single column partition

Re: [HACKERS] maintenance_work_mem and autovacuum

--On Donnerstag, März 26, 2009 13:43:45 -0700 Josh Berkus wrote: I actually have a client who does both automated and manual vacuums. Having two settings would definitely be convenient for them. I often found people doing this running within a) their own superuser with special GUCs set or b

Re: [HACKERS] maintenance_work_mem and autovacuum

Simon, Hmmm, perhaps the right way to do this is to have a user called "autovacuum" that is used to perform autovacuums. This makes sense, depending on which autovac params actually get picked up from the session. Seems like a nice small change for 8.4? Hmmm. Maybe not small enough. --

Re: [HACKERS] maintenance_work_mem and autovacuum

On Thu, 2009-03-26 at 13:43 -0700, Josh Berkus wrote: > > I agree with Magnus' original reasoning: we can have more than one > > autovacuum process, so we may have autovacuum_max_workers active and so > > the work mem they use must be smaller. For maintenance_work_mem we would > > typically only h

Re: [HACKERS] GIN versus zero-key queries

On Wed, 2009-03-25 at 13:25 -0400, Tom Lane wrote: > I am not sure whether the statement in 52.5 is still accurate, though. > We have an API definition by which extractQuery can distinguish "all > match" from "no match". If we just legislate that "some match" isn't > a valid behavior for zero-key

Re: [HACKERS] maintenance_work_mem and autovacuum

I agree with Magnus' original reasoning: we can have more than one autovacuum process, so we may have autovacuum_max_workers active and so the work mem they use must be smaller. For maintenance_work_mem we would typically only have one session using it at any time, so we either have to start har

Re: [HACKERS] Potential problem with HOT and indexes?

Greg Stark writes: > On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane wrote: >> I realized what was bothering me about that patch: it could reset >> indcheckxmin too soon, ie, while there are still transactions that >> shouldn't use the index. > That doesn't sound like the right solution. What we want

Re: [HACKERS] Potential problem with HOT and indexes?

On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane wrote: > Gregory Stark writes: >>> Another thought now though. What if someone updates the pg_index entry -- >>> since we never reset indcheckxmin then the new tuple will have a new xmin >>> and >>> will suddenly become invisible again for no reason. > >

Re: [HACKERS] Potential problem with HOT and indexes?

Gregory Stark writes: >> Another thought now though. What if someone updates the pg_index entry -- >> since we never reset indcheckxmin then the new tuple will have a new xmin and >> will suddenly become invisible again for no reason. > Fixing this for REINDEX is fairly straightforward I think. I

Re: [HACKERS] maintenance_work_mem and autovacuum

On Thu, 2009-03-26 at 19:46 +0100, Guillaume Smet wrote: > On Thu, Mar 26, 2009 at 7:34 PM, Simon Riggs wrote: > > Why do we have separate parameters for autovacuum and vacuum, except for > > maintenance_work_mem? > > > > Should we also have autovacuum_work_mem? > > We already discussed it here:

Re: [HACKERS] 8.4 open items list updated

Magnus Hagander writes: > Tom Lane wrote: >> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items >> Anybody who wants to start cleaning these things up, have at it. > We were in agreement to move the Win32 namespace issue to the TODO list, > right? Unless anybody objects, I'll go ahead and

Re: [HACKERS] 8.4 open items list updated

Tom Lane wrote: > Since Bruce seems not to be in a hurry to update his open-items mailbox, > I've taken the liberty of adding entries for all the items that I think > are relevant for 8.4 to the wiki page: > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items > > Anybody who wants to start c

Re: [HACKERS] tuplestore API problem

Simon Riggs writes: > Sounds very similar to the solution that you just removed from the hash > join code for performance reasons. Flushing memory when we overflow > sounds like an artifact from the time when tuplestore split from > tuplesort. Can't we keep the appropriate rows in memory and scrol

[HACKERS] 8.4 open items list updated

Since Bruce seems not to be in a hurry to update his open-items mailbox, I've taken the liberty of adding entries for all the items that I think are relevant for 8.4 to the wiki page: http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items Anybody who wants to start cleaning these things up, hav

Re: [HACKERS] maintenance_work_mem and autovacuum

On Thu, Mar 26, 2009 at 7:34 PM, Simon Riggs wrote: > Why do we have separate parameters for autovacuum and vacuum, except for > maintenance_work_mem? > > Should we also have autovacuum_work_mem? We already discussed it here: http://archives.postgresql.org/message-id/49353a69.20...@hagander.net

[HACKERS] maintenance_work_mem and autovacuum

Why do we have separate parameters for autovacuum and vacuum, except for maintenance_work_mem? Should we also have autovacuum_work_mem? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] display previous query string of idle-in-transaction

On Wed, 2009-03-25 at 18:08 +0900, Tatsuhito Kasahara wrote: > If we can also check previous query_string of idle-in-transaction, > it is useful for analysis of long transaction problem. I'm more interested in the problem itself. Why do you think there is a problem and why does knowing this help

Re: [HACKERS] tuplestore API problem

On Thu, 2009-03-26 at 12:57 -0400, Tom Lane wrote: > If work_mem is small enough, that means the tuplestore is > forced into dump-to-disk mode, which means it releases all its > in-memory tuples. And guess what: the ScanTupleSlot is pointing at > one of those, it doesn't have its own copy of the

Re: [HACKERS] Potential Join Performance Issue

"Lawrence, Ramon" writes: > Attached is a patch that will disable the physical-tlist optimization > for hash join if the number of batches is greater than 1. The patch and > performance results were created by Michael Henderson (graduate > student). I've applied the attached modified version of

[HACKERS] tuplestore API problem

By chance I discovered that this query in the regression tests SELECT ntile(NULL) OVER (ORDER BY ten, four), ten, four FROM tenk1 LIMIT 2; stops working if work_mem is small enough: it either dumps core or delivers wrong answers depending on platform. After some tracing I found out the reason.

Re: [HACKERS] Crash in gist insertion on pathological box data

On Thu, Mar 26, 2009 at 5:39 PM, Andrew Gierth wrote: > A user on IRC reported a crash (backend segfault) in GiST insertion > (in 8.3.5 but I can reproduce this in today's HEAD) that turns out > to be due to misbehaviour of gist_box_picksplit. > Andrew, thank you for the test case and report. p.

Re: [HACKERS] global index - work in progress patch

"Srinath K" writes: > DISCLAIMER > == > This e-mail may contain privileged and confidential information which > is the property of Persistent Systems Ltd. If you want to submit patches, you're really going to have to get your corporate lawyers to let you submit them without this disclaime

Re: [HACKERS] global index - work in progress patch

On Thu, Mar 26, 2009 at 2:16 PM, Srinath K wrote: > I'm implementing "global index" - an index that indexes all tables in an > inheritance hierarchy. For complete feature description, please refer > README.user. > ... > This e-mail may contain privileged and confidential information which is the

[HACKERS] Crash in gist insertion on pathological box data

A user on IRC reported a crash (backend segfault) in GiST insertion (in 8.3.5 but I can reproduce this in today's HEAD) that turns out to be due to misbehaviour of gist_box_picksplit. The nature of the problem is this: if gist_box_picksplit doesn't find a good disposition on the first try, then it

Re: [HACKERS] pg_dump Add dumping of comments on index columns

Hi. > Since we are about to go to beta, it may be that no one is up for > reviewing it right now.  But I've added it to the CommitFest page for > the next CommitFest. Thank you. I wait until the next CommitFest. - Taro Minowa(Higepon) http://www.monaos.org/ http://code.google.com/p/mosh-sch

Re: [HACKERS] pg_dump Add dumping of comments on index columns

> Would someone please review this? Since we are about to go to beta, it may be that no one is up for reviewing it right now. But I've added it to the CommitFest page for the next CommitFest. http://wiki.postgresql.org/wiki/CommitFest_2009-First ...Robert -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] New trigger option of pg_standby

Hi Simon. On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs wrote: > Earlier, we discussed having a single trigger file that contains an > option rather than two distinct trigger files. That design is better > because it allows the user to choose at failover time, rather than > making a binding decis

Re: [HACKERS] 8.4 release notes proof reading 1/2

Bruce, Here is the second set of comments: - pg_hba.conf: it seems to me the format has changed which may break existing pg_hba.conf (it broke the default one of the RPM packaging). We should make it very visible as the format hasn't changed for a while. I suppose we'll put it at the top but I ju

Re: [HACKERS] small but useful patches for text search

On Wednesday 25 March 2009 23:17:41 Robert Haas wrote: > With respect to this item: > Disable appending of the epoch date/time when '%' escapes are missing > in log_filename (Robert Haas) > I might suggest explaining it this way: > This change makes it easier to use PostgreSQL in conjunction with a

Re: [HACKERS] display previous query string of idle-in-transaction

ITAGAKI Takahiro wrote: The feature could be achieved by an extension module using new executor hooks in 8.4. It is just like contrib/pg_stat_statements; Well, it is a good idea. Displaying last-query-string may be useful, but it is not a feature for general purpose. So, it may be an external

Re: [HACKERS] New trigger option of pg_standby

On Thu, 2009-03-26 at 08:32 +0100, Guillaume Smet wrote: > On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao wrote: > > What does "the default" mean? You mean that new trigger should use > > the existing trigger option character (-t)? > > Yes, that's my point. > > I understand it seems weird to swit

Re: [HACKERS] New trigger option of pg_standby

Hi, Guillaume Smet wrote: On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao wrote: What does "the default" mean? You mean that new trigger should use the existing trigger option character (-t)? Yes, that's my point. I understand it seems weird to switch the options but I'm pretty sure a lot of p

Re: [HACKERS] display previous query string of idle-in-transaction

Tatsuhito Kasahara wrote: > So, main purpose of displaying the last query string is .. > - check whether "idle in transaction (running long time) process >after SOME SQL" is exists or not. > - check the content of "SOME SQL". The feature could be achieved by an extension module using new ex

[HACKERS] 8.4 release notes proof reading 1/2

Hi, Just to warn people that I'm making a comprehensive proof reading of the release notes. Here are the first comments: - "This was available previously via a configure --enable-integer-datetimes (Neil Conway)" -> I don't think we need Neil's name in the details - "New semi- and ansi-joins (Tom

Re: [HACKERS] SSL over Unix-domain sockets

Bruce Momjian wrote: I thought the logical solution to this was to place the socket in a secure directory and not bother with SSL at all. How would a client algorithmically determine whether the server socket was in a "secure" directory? -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] display previous query string of idle-in-transaction

Guillaume Smet wrote: On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski wrote: I would love to get it, but when I suggested it some time in the past Tom shot it down as bad idea. http://archives.postgresql.org/message-id/20071016132131.ga4...@depesz.com I agree with Tom here. I trac

Re: [HACKERS] pg_dump Add dumping of comments on index columns

Hi. Here is a patch for pg_dump "Commenting on a composite-type column". This patch is for Todo item named "Add dumping of comments on index columns and composite type columns". As Tom Lane said, this patch is not for dumping "comments on index columns", but only for "comment on composite-type col

Re: [HACKERS] New trigger option of pg_standby

On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao wrote: > What does "the default" mean? You mean that new trigger should use > the existing trigger option character (-t)? Yes, that's my point. I understand it seems weird to switch the options but I'm pretty sure a lot of persons currently using -t w