Re: [HACKERS] [pgsql-hackers-win32] Current Win32 port status
Claudio Natoli wrote: Hi all, just a small note to anyone who is interested in the status of this port. Firstly, the fork/exec changes are coming along well. The first patch, for fork/exec'ing of backends has been accepted and applied. A second patch, for fork/exec'ing of the remainder of the postgres process has just been submitted for review. Two patches (which are essentially already completed) will follow this; the first to allow some further rearrangement of the postmaster fork/execs in preparation for the Win32 CreateProcess calls, and the final patch will place the actual CreateProcess calls into the code-base. It is reasonable to expect that we will have this changes in place within a few weeks. At that point, we will be within striking distance of a Win32 port. The only remaining barriers to a running, albeit imperfect, implementation are: * signals (non-trivial, to say the least, but encouraging to see discussion occurring in this regard), * a workable pipe replacement I don't have 'pipe' mentioned on the win32 patch. Can you give details? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
Are we going to regenerate the 7.4.1 tar ball? -- Tatsuo Ishii Peter Eisentraut - PostgreSQL wrote: CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/12/21 17:36:34 Modified files: doc/src/sgml : Tag: REL7_4_STABLE release.sgml Log message: Some refining of release notes. Markup is still broken by someone else, so I cannot remake HISTORY. I have regenerated HISTORY in 7.4.x and HEAD. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] COPY TABLE TO
Hi, I need to write a tab separated text file such that the first row contains number of records in the table. I insert first row with '0' (zero) as first column rest columns NULL. Then at the end of writing records to table I do a select into Variable count(*) from table. update the first record with the count returned. Unfortunately after the update the first row becomes the last row hence COPY TO FileName sends the count as the last record. I need count as the first record? Any suggestions please ? The documentation says indexing does not affect copy order. I am developing on C++ with PostGre on windows. I need to port to Linux later. Any suggestions on linking C++ code to PostGre (queries functions) Thanks Paul ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [pgsql-hackers-win32] Current Win32 port status
Bruce Momjian wrote: * a workable pipe replacement I don't have 'pipe' mentioned on the win32 patch. Can you give details? Yeah you do. The second point under Problems with select(). Basically, the Win32 call to pipe() returns a file descriptor which is invalid to pass on to Win32 select() (as it only takes socket handles). So, we need to replace the select'ing mechanism under Win32 (yech), or write a Win32 pipe() replacement that returns two socket endpoints (good enough for our purposes), or something else... Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] COPY TABLE TO
On Mon, Dec 22, 2003 at 10:35:08AM -, Paul Punett wrote: I need to write a tab separated text file such that the first row contains number of records in the table. Whether COPY does what you want may depend on what you want to do with special characters. If your table contains strings with strange characters like newline, tab, non-ASCII characters etc. then COPY will replace them by escape sequences. I guess in most cases you won't have any problems with this, but it's a thing to keep in mind. I need count as the first record? Any suggestions please ? The documentation says indexing does not affect copy order. Rather than tricking COPY into generating your file format, you may want to use COPY TO STDOUT and do some processing on the lines you get from that. I am developing on C++ with PostGre on windows. I need to port to Linux later. Any suggestions on linking C++ code to PostGre (queries functions) Try libpqxx (http://pqxx.tk/). Use the tablereader class to read raw lines from your table and write them to your file. Something like this should do the trick: connection c(myoptions); transactionserializable t(c); result count = t.exec(select count(*) from + mytable); myfile count[0][0] endl; tablereader reader(t, mytable); string line; while (reader.get_raw_line(line)) myfile line endl; This may be a bit slower than a direct COPY because the data has to go through your program rather than directly to the file, but it gives you more control over the file's format. (I used a serializable transaction here because otherwise rows may be added or deleted by somebody else at just the wrong moment, e.g. after the count but before we read the table) Jeroen PS - It's Postgres or PostgreSQL, not PostGre! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
Tatsuo Ishii [EMAIL PROTECTED] writes: Are we going to regenerate the 7.4.1 tar ball? No. There is no difference other than some trailing spaces between what Bruce committed and what I put in yesterday. (It might be good if we had a more standardized way of generating HISTORY though. I tried a couple different versions of lynx and got a couple different outputs, none perfectly matching whatever version Bruce is using ...) regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] COPY TABLE TO
Paul Punett [EMAIL PROTECTED] writes: I need count as the first record? Any suggestions please ? SQL does not guarantee any particular ordering of rows in a table. You cannot do what you're doing and expect it to be reliable. You could do something like this: add a sequence-number column to your table and then do SELECT ... ORDER BY seqno to extract the data in a controlled order. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
On Mon, 22 Dec 2003, Tom Lane wrote: Tatsuo Ishii [EMAIL PROTECTED] writes: Are we going to regenerate the 7.4.1 tar ball? No. There is no difference other than some trailing spaces between what Bruce committed and what I put in yesterday. (It might be good if we had a more standardized way of generating HISTORY though. I tried a couple different versions of lynx and got a couple different outputs, none perfectly matching whatever version Bruce is using ...) Is this something that could be added to the 'make dist' target, so that it happens as part of the bundle build? or maybe a 'make release_prep' target could be created, that would include stuff like this that gets done just before release? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] COPY TABLE TO
SELECT x, y (SELECT 1 AS ord, COUNT(*) as x, NULL AS y FROM tablex UNION SELECT 2, x, y FROM tablex) May be you will have to do some explicit casting depending on the field types. -- Paulo Scardine - Original Message - From: Paul Punett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 22, 2003 8:35 AM Subject: [HACKERS] COPY TABLE TO Hi, I need to write a tab separated text file such that the first row contains number of records in the table. I insert first row with '0' (zero) as first column rest columns NULL. Then at the end of writing records to table I do a select into Variable count(*) from table. update the first record with the count returned. Unfortunately after the update the first row becomes the last row hence COPY TO FileName sends the count as the last record. I need count as the first record? Any suggestions please ? The documentation says indexing does not affect copy order. I am developing on C++ with PostGre on windows. I need to port to Linux later. Any suggestions on linking C++ code to PostGre (queries functions) Thanks Paul ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
Marc G. Fournier [EMAIL PROTECTED] writes: On Mon, 22 Dec 2003, Tom Lane wrote: (It might be good if we had a more standardized way of generating HISTORY though. I tried a couple different versions of lynx and got a couple different outputs, none perfectly matching whatever version Bruce is using ...) Is this something that could be added to the 'make dist' target, so that it happens as part of the bundle build? Not a bad idea. AFAICS we have the generation of HISTORY down to a script now; there's no reason for it to be in CVS at all. It'd be nice to do the same for INSTALL, but I'm not sure if that takes any manual twiddling or not. (Peter?) The version of lynx that's on cvs.postgresql.org seems to produce okay output (it's what I ended up using yesterday), so standardizing on that wouldn't be a problem. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cascading column drop to index predicates
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: The thing is, if you drop a column that is used in a normal index, yes the index is now useless - drop it. However, since you can have (and I have) indexes like this: CREATE INDEX asdf ON table (a, b, c) WHERE d IS NOT NULL; If I drop column d, there is no way I want that index to just disappear! Uh, why not? I don't quite see the argument why d stands in a different relationship to this index than a,b,c do. The index is equally meaningless without any of them. Can we change it to requiring a CASCADE? It'd likely be a simple code change, but first let's have the argument why it's a good idea. In that sample mentioned the index might be used mostly with a,b columns. Dropping the index silently might damage the application because it relies on an (a,b) index to be present. IMHO only Indexes that span that single column should be dropped without CASCADE. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cascading column drop to index predicates
Andreas Pflug [EMAIL PROTECTED] writes: In that sample mentioned the index might be used mostly with a,b columns. Dropping the index silently might damage the application because it relies on an (a,b) index to be present. IMHO only Indexes that span that single column should be dropped without CASCADE. That argument makes no sense to me at all. If you drop the *column* a or b, and do not thereby break your application, how is the disappearance of the index on it going to break anything? The index is meaningless without something to index. I think the question at hand is whether the same logic applies to partial indexes: if the index's condition is no longer meaningful, is the index meaningful? I think we can handle both cases the same way. But clearly an index condition isn't quite the same thing as an index column, so maybe someone can make a good argument for treating them differently. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cascading column drop to index predicates
On Mon, 2003-12-22 at 10:55, Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: In that sample mentioned the index might be used mostly with a,b columns. Dropping the index silently might damage the application because it relies on an (a,b) index to be present. IMHO only Indexes that span that single column should be dropped without CASCADE. That argument makes no sense to me at all. If you drop the *column* a or b, and do not thereby break your application, how is the disappearance of the index on it going to break anything? The index is meaningless without something to index. I think Andreas is trying to argue that if you drop column b from index (a, b) that the index should be converted into index(a) -- assuming of course there isn't already an index(a). ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Project status pages
On Fri, 19 Dec 2003, Bruce Momjian wrote: Robert Treat wrote: Wasn't there a patch posted many months ago for PITR. IIRC it wasn't complete, but would be a good starting point for those interested in helping out. If it's in the archives it would be nice to add a link to it on the project page... which brings up the question on whats the process for updating these pages? Perhaps they should be moved into the wiki framework up on techdocs? They are just web pages. If someone want to set up wiki and pull the content, I can remove my versions. http://techdocs.postgresql.org/guides is an open wiki instance, you could just put it there. I've edited a couple of pages there. Nothing fancy, but it is pretty easy to edit. You don't (or didn't have to until recently if it's changed) have to register to use it. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cascading column drop to index predicates
Rod Taylor [EMAIL PROTECTED] writes: I think Andreas is trying to argue that if you drop column b from index (a, b) that the index should be converted into index(a) -- assuming of course there isn't already an index(a). That seems to be well outside the charter of DROP CASCADE. I think we either drop or don't drop; we don't go building new indexes, which is what this would take. There are also definitional problems --- for instance, if the index is UNIQUE, does it transmogrify into a UNIQUE constraint on A alone (which would most likely fail)? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] cascading column drop to index predicates
Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: I think Andreas is trying to argue that if you drop column b from index (a, b) that the index should be converted into index(a) -- assuming of course there isn't already an index(a). That seems to be well outside the charter of DROP CASCADE. I think we either drop or don't drop; we don't go building new indexes, which is what this would take. There are also definitional problems --- for instance, if the index is UNIQUE, does it transmogrify into a UNIQUE constraint on A alone (which would most likely fail)? Agreed, auto creation wouldn't be necessary/expected. If you drop, objects disappear, you don't expect them to morph. But I'd like to be inhibited to drop the column if it requires a somewhat recreated index on (a). So IMHO a DROP INDEX [RESTRICT] should drop only dependent objects if this won't affect others. Regards, Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Postgres respond after toomany times to a query view
Title: Postgres respond after toomany times to a query view Hi, I developing a program using postgres and linux like operating system. My problem is this: I have a quite complicated view with roughly 1 record. When I execute a simple query like this select * from myview postgres respond after 50 - 55 minutes roughly. I hope that someone can help me with some suggestion about reason of this behavior and some solution to reduce time ti have results. Thank you for your attentions and I hope to receive some feedback as soon as possible
Re: [HACKERS] 7.4 include file conflict
I would like to mention that I am on MacOS 10.3 and have this issue when compiling PHP with both iODBC support and Postgres support at the same time. I have to specify the -I/usr/include and the -I/usr/local/pgsql/include in order for the build scripts to run correctly. the problem is that at build time when building iODBC it may or may not look in /usr/include first depending on when the flags were placed. Moving the file to ecpg/sqltypes.h should do the trick because anything other than postgres should not traverse into ecpg/ unless specifically looking for it. Not sure if that breaks any user programs as someone else noted. Thanks. Ray A. At 9:39 AM +0100 12/17/03, Michael Meskes wrote: On Tue, Dec 16, 2003 at 07:00:25PM -0500, Bruce Momjian wrote: Are you saying some programs will look in /usr/include before looking in -I specified directories, and that is the whole problem? If so, that is 100% wrong and we don't have to fix our files to workaround this. No I meant to say that you will alsways get our file and not the one in /usr/include. That means you must not specify our -I option if you need the file in /usr/include. Since this file may be needed together with pgsql The best way seems to be moving just the compat headers IMO. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Suggestions welcome for PhD topic in Distributed Database Systems (Planning to contribute to postgresql)
Dear All, I am planning to commit my PhD work (Under NDSU.edu) to further develop PostGreSQL so that it can emerge as a major player in the distributed grid computing. Please send me if you have any suggestions ... Sincerely Syed Mamun Raihan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] postgres does not respond to a query view of 10000 records roughl y
Title: postgres does not respond to a query view of 1 records roughly Hi, I developing a program usinn postgres and linux like system operation. My problem is this: I have a view quite complicated with roughly 1 record. When I execute a simple query like this select * from myview postgres does not respond and does not produce any results. I hope that someone can help me with some suggestion about reason of this behavior and some solution to avoid it. Thank you for your attentions and I hope to receive some feedback as soon as possible
[HACKERS] Permissions and PGSQL
Hi, I use PgSql for a lot of our company's need and I lack some features. I would like to know if there is plans to implement: - User permissions based on columns? (Ex: User1 has Select on Column CompayName but User2 has update on column CompanyName while User3 has create new row on table). - Permissions on create table. This is the most lacking permission problem actually, since everyone that can log in PgSql can create tables... Thanks to share ideas and on going work. -jec ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Postgres respond after toomany times to a query view
Title: Postgres respond after toomany times to a query view It wouldhelp us to help you if you posted the view, tables involved and indexes on those table. Also things like some of the postgresql.conf parameters would help. Things like "effective_cache_size", "sort_mem". Also how often the tables in the views are update and how often you vacuum analyzewill have a big impact on performance. - Original Message - From: Claudia D'amato To: [EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 3:15 AM Subject: [HACKERS] Postgres respond after toomany times to a query view Hi, I developing a program using postgres and linux like operating system. My problem is this: I have a quite complicated view with roughly 1 record. When I execute a simple query like this "select * from myview" postgres respond after 50 - 55 minutes roughly. I hope that someone can help me with some suggestion about reason of this behavior and some solution to reduce time ti have results. Thank you for your attentions and I hope to receive some feedback as soon as possible
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Tom Lane wrote: Tatsuo Ishii [EMAIL PROTECTED] writes: Are we going to regenerate the 7.4.1 tar ball? No. There is no difference other than some trailing spaces between what Bruce committed and what I put in yesterday. (It might be good if we had a more standardized way of generating HISTORY though. I tried a couple different versions of lynx and got a couple different outputs, none perfectly matching whatever version Bruce is using ...) Right. I regenerated because Peter had mentioned he was getting poor output, so I figured I should make sure it was fresh, but the changes were just trailing spaces. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Mon, 22 Dec 2003, Tom Lane wrote: (It might be good if we had a more standardized way of generating HISTORY though. I tried a couple different versions of lynx and got a couple different outputs, none perfectly matching whatever version Bruce is using ...) Is this something that could be added to the 'make dist' target, so that it happens as part of the bundle build? Not a bad idea. AFAICS we have the generation of HISTORY down to a script now; there's no reason for it to be in CVS at all. It'd be nice to do the same for INSTALL, but I'm not sure if that takes any manual twiddling or not. (Peter?) INSTALL pulls the release number from configure.in, or configure. The version of lynx that's on cvs.postgresql.org seems to produce okay output (it's what I ended up using yesterday), so standardizing on that wouldn't be a problem. I have: Lynx Version 2.8.3rel.1 (23 Apr 2000) Built on bsdi4.3 Jun 5 2001 12:07:55 and I see postgresql.org has: Lynx Version 2.8.5dev.16 (01 Jun 2003) libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.7b Built on freebsd4.8 Sep 1 2003 04:28:28 The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Project status pages
scott.marlowe wrote: On Fri, 19 Dec 2003, Bruce Momjian wrote: Robert Treat wrote: Wasn't there a patch posted many months ago for PITR. IIRC it wasn't complete, but would be a good starting point for those interested in helping out. If it's in the archives it would be nice to add a link to it on the project page... which brings up the question on whats the process for updating these pages? Perhaps they should be moved into the wiki framework up on techdocs? They are just web pages. If someone want to set up wiki and pull the content, I can remove my versions. http://techdocs.postgresql.org/guides is an open wiki instance, you could just put it there. I've edited a couple of pages there. Nothing fancy, but it is pretty easy to edit. You don't (or didn't have to until recently if it's changed) have to register to use it. I think it is just easier for me to edit the HTML. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-advocacy] PostgreSQL speakers needed for OSCON 2004
I'd rather pay the high fees and actually have access to the money ... Paypal I'm 110% *against* ... they have had *way* too many problems. In fact, there was a time when we ourselves setup the whole paypal account and were looking at moving to it, until our clients started telling us they wouldn't use it. We, as a business, have had something like 25 new clients sign up in the past month that its turning out are cards stolen from clients who made purchases through paypal in the recent past ... All due respect but that is just bad mojo in general. We have had zero problems with paypal. We also don't use them as our primary payment. We use a real merchant account and checking account for that. However paypal is good for a lot of things. Namely you want to provide the most ways to get paid (perfect for donations). It has also greatly increased its security and viability sense that really big billion dollar company call E-bay bought it. We (ie. Hub) just went through re-evaluating our online credit card services, and are currently in the middle of moving our accounts to a company called PaySystems (http://www.paysystems.com) that we've found to We use Echo, which also accepts electronic check but remember we are talking about donations here, not a for profit accepting credit cards. Sincerely, Joshua D. Drake have some of the better fees, and have yet to any major complaints about their services ... we haven't found any major complaints about our current one, but we just find we're losing too much money in the way of fees ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
On Mon, Dec 22, 2003 at 12:17:32PM -0500, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. What about having them generated from some Make target, so the curious user could generate it on his own, and is also built by Marc's ficticious package-prep target? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) El sabio habla porque tiene algo que decir; el tonto, porque tiene que decir algo (Platon). ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
On Mon, 22 Dec 2003, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. Confused here, but how up to date is HISTORY in CVS to start with? I don't go out of my way to watch for them, but commits to HISTORY don't seem to be all that often to start with ... and how many ppl actually look at the HISTORY file *except* at release time? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Marc G. Fournier wrote: On Mon, 22 Dec 2003, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. Confused here, but how up to date is HISTORY in CVS to start with? I don't go out of my way to watch for them, but commits to HISTORY don't seem to be all that often to start with ... and how many ppl actually look at the HISTORY file *except* at release time? Usually I modify HISTORY during beta, then move it to release.sgml, but I could reverse that and do edits in release.sgml then regenerate and copy HISTORY. It is mostly during beta. We could throw a URL into the HISTORY file telling people where to look for the generated release notes. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Alvaro Herrera wrote: On Mon, Dec 22, 2003 at 12:17:32PM -0500, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. What about having them generated from some Make target, so the curious user could generate it on his own, and is also built by Marc's ficticious package-prep target? He would have to have the SGML tools installed, and that isn't trivial/likely. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
On Mon, 22 Dec 2003, Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 22 Dec 2003, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. Confused here, but how up to date is HISTORY in CVS to start with? I don't go out of my way to watch for them, but commits to HISTORY don't seem to be all that often to start with ... and how many ppl actually look at the HISTORY file *except* at release time? Usually I modify HISTORY during beta, then move it to release.sgml, but I could reverse that and do edits in release.sgml then regenerate and copy HISTORY. It is mostly during beta. We could throw a URL into the HISTORY file telling people where to look for the generated release notes. I'm neither here nor there on it ... it just seems weird to include 'derived files' in CVS that really aren't required (ie. bison stuff is required) ... IMHO, it would be like re-generating the whole docs and checking it into CVS ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
On Mon, 22 Dec 2003, Bruce Momjian wrote: Alvaro Herrera wrote: On Mon, Dec 22, 2003 at 12:17:32PM -0500, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. What about having them generated from some Make target, so the curious user could generate it on his own, and is also built by Marc's ficticious package-prep target? He would have to have the SGML tools installed, and that isn't trivial/likely. True, but Peter could very easily have HISTORY generated and on the web page as part of his docs build process ... then 'HISTORY' in CVS would just be a URL to that online version, while 'HISTORY' in a release would be the full HISTORY file ... ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Marc G. Fournier wrote: On Mon, 22 Dec 2003, Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 22 Dec 2003, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. Confused here, but how up to date is HISTORY in CVS to start with? I don't go out of my way to watch for them, but commits to HISTORY don't seem to be all that often to start with ... and how many ppl actually look at the HISTORY file *except* at release time? Usually I modify HISTORY during beta, then move it to release.sgml, but I could reverse that and do edits in release.sgml then regenerate and copy HISTORY. It is mostly during beta. We could throw a URL into the HISTORY file telling people where to look for the generated release notes. I'm neither here nor there on it ... it just seems weird to include 'derived files' in CVS that really aren't required (ie. bison stuff is required) ... IMHO, it would be like re-generating the whole docs and checking it into CVS ... Agreed, it is weird. One idea would be to check a HISTORY file into CVS that contains only a link to the developer HTML docs, then overwrite it with the proper contents on tar build. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Marc G. Fournier wrote: On Mon, 22 Dec 2003, Bruce Momjian wrote: Alvaro Herrera wrote: On Mon, Dec 22, 2003 at 12:17:32PM -0500, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. What about having them generated from some Make target, so the curious user could generate it on his own, and is also built by Marc's ficticious package-prep target? He would have to have the SGML tools installed, and that isn't trivial/likely. True, but Peter could very easily have HISTORY generated and on the web page as part of his docs build process ... then 'HISTORY' in CVS would just be a URL to that online version, while 'HISTORY' in a release would be the full HISTORY file ... ? Yep, I just came to the same conclusion. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
On Mon, 22 Dec 2003, Bruce Momjian wrote: The only problem with removing HISTORY from CVS is that we will not have an easily reable list of release changes _until_ we package the release. Nonsense. Point 'em to http://developer.postgresql.org/docs/postgres/release.html Perhaps we should keep HISTORY in CVS, but regenerate it on tarball packaging, and INSTALL too. It's really bogus to have two versions of the same information in CVS. If we simply agreed that the SGML versions are the masters, we could keep those up-to-date, and generate the plain-text versions whenever a tarball is rolled. Marc G. Fournier [EMAIL PROTECTED] writes: Confused here, but how up to date is HISTORY in CVS to start with? One reason it's not is the confusion over which version is the master. Last cycle, Peter encouraged people to add quick-and-dirty release notes into release.sgml when important changes are made, and I thought that worked pretty well. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Confused here, but how up to date is HISTORY in CVS to start with? One reason it's not is the confusion over which version is the master. Last cycle, Peter encouraged people to add quick-and-dirty release notes into release.sgml when important changes are made, and I thought that worked pretty well. Would you be more specific? How did it work well? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TODO list
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane said: On an implementation level, where are you thinking of enforcing this? Without digging deeply at all I thought probably in the postmaster. Nah, that's a nonstarter, because the postmaster has basically no information about its children except for their PIDs and cancel keys. In particular it does not know which database or user each one is for, and really can't because the connection request packet is not input from the client connection until after fork(). AFAICS there's really no other way to get this information than by looking in shared memory. The PGPROC array already has info about connected databases. I don't think it stores info about session user, but that would be an easy and cheap addition. I'm not at all dogmatic about using pg_hba.conf - it just seemed similar to the info we carry there. It's not necessarily a bad idea; we'd just need to adjust our theory about when the cached pg_hba.conf data can be freed. Did we reach a concensus about how this should be done? From a config file? If so, should it be pg_hba.conf? Or from a table? cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql-server/doc/src/sgml Tag: REL7_4_STABLE r ...
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Last cycle, Peter encouraged people to add quick-and-dirty release notes into release.sgml when important changes are made, and I thought that worked pretty well. Would you be more specific? How did it work well? There was a place for people to look to see what interesting stuff was in CVS tip. We had about thirty entries at the end of the 7.4 devel cycle: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/doc/src/sgml/release.sgml?rev=1.208content-type=text/x-cvsweb-markup Now, I dunno how many people actually made use of it, but if it were publicized and maintained more faithfully, I think people would use it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
