[COMMITTERS] pgsql-server/src/backend/postmaster pgstat.c
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 11:44:40 Modified files: src/backend/postmaster: pgstat.c Log message: Remove check on source address of a statistics packet. Check was broken by recent IPv6 changes, and since it's redundant with a kernel-level check anyway, it seems not worth trying to fix it. Per recent discussions. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 12:26:54 Modified files: doc/src/sgml : runtime.sgml src/backend/optimizer/geqo: geqo_main.c src/backend/utils/misc: guc.c postgresql.conf.sample src/bin/psql : tab-complete.c src/include/optimizer: geqo.h Log message: Remove geqo_random_seed parameter. Having geqo reset the global random() sequence every time it's called is bogus --- it interferes with user control over the seed, and actually decreases randomness overall (because a seed based on time(NULL) is pretty predictable). If you really want a reproducible result from geqo, do 'set seed = 0' before planning a query. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[COMMITTERS] pgsql-server/contrib/chkpass chkpass.c
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 12:27:25 Modified files: contrib/chkpass: chkpass.c Log message: Remove another useless, counterproductive srandom() call. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Tom Lane wrote: > CVSROOT: /cvsroot > Module name: pgsql-server > Changes by: [EMAIL PROTECTED] 03/09/07 12:26:54 > > Modified files: > doc/src/sgml : runtime.sgml > src/backend/optimizer/geqo: geqo_main.c > src/backend/utils/misc: guc.c postgresql.conf.sample > src/bin/psql : tab-complete.c > src/include/optimizer: geqo.h > > Log message: > Remove geqo_random_seed parameter. Having geqo reset the global random() > sequence every time it's called is bogus --- it interferes with user > control over the seed, and actually decreases randomness overall > (because a seed based on time(NULL) is pretty predictable). If you really > want a reproducible result from geqo, do 'set seed = 0' before planning > a query. Tom, I see 'set seed' works: test=> set seed = 0; SET but where is it documented? -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom, I see 'set seed' works: > test=> set seed = 0; > SET > but where is it documented? On the SET reference page. It's not in runtime.sgml because we don't allow non-interactive settings (which might or might not be a reasonable restriction, but it's been there awhile without complaints). 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: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom, I see 'set seed' works: > > test=> set seed = 0; > > SET > > but where is it documented? > > On the SET reference page. It's not in runtime.sgml because we don't > allow non-interactive settings (which might or might not be a reasonable > restriction, but it's been there awhile without complaints). So that is how testers could get consistent ANALYZE statistics? -- 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: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Bruce Momjian <[EMAIL PROTECTED]> writes: > So that is how testers could get consistent ANALYZE statistics? Yeah, that too. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[COMMITTERS] pgsql-server/. configure.in
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 13:38:05 Modified files: . : configure.in Log message: Add $srcdir for Win32 builds, from Peter. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[COMMITTERS] pgsql-server/. configure
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 13:49:41 Modified files: . : configure Log message: autoconf run. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[COMMITTERS] pgsql-server/ /Tag: /WIN32_DEV /configure /con ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 18:44:31 Modified files: . : Tag: WIN32_DEV configure configure.in contrib/chkpass: Tag: WIN32_DEV chkpass.c doc/src/sgml : Tag: WIN32_DEV runtime.sgml src/backend/optimizer/geqo: Tag: WIN32_DEV geqo_main.c src/backend/postmaster: Tag: WIN32_DEV pgstat.c src/backend/utils/misc: Tag: WIN32_DEV guc.c postgresql.conf.sample src/bin/psql : Tag: WIN32_DEV tab-complete.c src/include/optimizer: Tag: WIN32_DEV geqo.h Log message: Update WIN32 branch from CVS HEAD. ---(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
[COMMITTERS] pgsql-server/doc FAQ src/FAQ/FAQ.html
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 19:01:42 Modified files: doc: FAQ doc/src/FAQ: FAQ.html Log message: Update URL to be momjian.postgresql.org. ---(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
[COMMITTERS] pgsql-server/doc FAQ src/FAQ/FAQ.html
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 19:02:54 Modified files: doc: FAQ doc/src/FAQ: FAQ.html Log message: Update URL. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 19:51:55 Added files: src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c bootstrap_tokens.h src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c preproc.h src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c Log message: Add bison/lex created files. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[COMMITTERS] pgsql-server/. Tag: WIN32_DEV configure
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 20:34:05 Modified files: . : Tag: WIN32_DEV configure Log message: Force flex/bison output files to be current. ---(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
[COMMITTERS] pgsql-server/. Tag: WIN32_DEV configure config ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 20:39:04 Modified files: . : Tag: WIN32_DEV configure configure.in Log message: For flex/bison files to be new. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[COMMITTERS] pgsql-server/. Tag: WIN32_DEV configure config ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 20:40:52 Modified files: . : Tag: WIN32_DEV configure configure.in Log message: Force flex/bison files to be new. ---(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
[COMMITTERS] pgsql-server/src/backend/libpq ip.c
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 21:56:13 Modified files: src/backend/libpq: ip.c Log message: Avoid using s_addr as a local variable name, to work around broken system headers on Unixware. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
[EMAIL PROTECTED] (Bruce Momjian) writes: > Added files: > src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c > bootstrap_tokens.h > src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c > src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c >preproc.h > src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c > Log message: > Add bison/lex created files. I thought the consensus of the discussion was that this was not necessary. It sure doesn't strike me as a good idea. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[COMMITTERS] pgsql-server/. Tag: WIN32_DEV configure config ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/07 22:55:52 Modified files: . : Tag: WIN32_DEV configure configure.in Log message: flex/bison stamp fix. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Tom Lane wrote: > [EMAIL PROTECTED] (Bruce Momjian) writes: > > Added files: > > src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c > >bootstrap_tokens.h > > src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c > > src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c > > preproc.h > > src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c > > > Log message: > > Add bison/lex created files. > > I thought the consensus of the discussion was that this was not > necessary. It sure doesn't strike me as a good idea. This is only in the WIN32_DEV, where installing bison/flex is a pain. I copy the needed files over manually when I update that CVS from 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I thought the consensus of the discussion was that this was not >> necessary. It sure doesn't strike me as a good idea. > This is only in the WIN32_DEV, where installing bison/flex is a pain. I > copy the needed files over manually when I update that CVS from HEAD. That's not a pain? You don't expect that WIN32_DEV will be broken on a regular basis because its derived files are out of date? Mind you, I do not actually give a darn whether WIN32_DEV is broken. What bothers me about this is that if it's considered a good idea for WIN32_DEV (whose only users, presumably, are developers clueful enough to obtain the needed tools for themselves) then whenever Windows support gets merged back to HEAD, we will be feeling pressure to do the same in the HEAD branch. And that is something up with which I will not put. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I thought the consensus of the discussion was that this was not > >> necessary. It sure doesn't strike me as a good idea. > > > This is only in the WIN32_DEV, where installing bison/flex is a pain. I > > copy the needed files over manually when I update that CVS from HEAD. > > That's not a pain? You don't expect that WIN32_DEV will be broken on a > regular basis because its derived files are out of date? > > Mind you, I do not actually give a darn whether WIN32_DEV is broken. > What bothers me about this is that if it's considered a good idea for > WIN32_DEV (whose only users, presumably, are developers clueful enough > to obtain the needed tools for themselves) then whenever Windows support > gets merged back to HEAD, we will be feeling pressure to do the same in > the HEAD branch. And that is something up with which I will not put. It is just easier for them to get start. Yea, they will need it when it is merged. -- 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: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Tom Lane wrote: > > >> I thought the consensus of the discussion was that this was not > > >> necessary. It sure doesn't strike me as a good idea. > > > > > This is only in the WIN32_DEV, where installing bison/flex is a pain. I > > > copy the needed files over manually when I update that CVS from HEAD. > > > > That's not a pain? You don't expect that WIN32_DEV will be broken on a > > regular basis because its derived files are out of date? > > > > Mind you, I do not actually give a darn whether WIN32_DEV is broken. > > What bothers me about this is that if it's considered a good idea for > > WIN32_DEV (whose only users, presumably, are developers clueful enough > > to obtain the needed tools for themselves) then whenever Windows support > > gets merged back to HEAD, we will be feeling pressure to do the same in > > the HEAD branch. And that is something up with which I will not put. > > It is just easier for them to get start. Yea, they will need it when it > is merged. Also, keep in mind that in the end most folks will be building under MinGW using a release tarball, that has those output files. We haven't gotten a MinGW release yet, so they have to build all the stuff. I use my unix bison/flex to build, but other's don't have that capability. -- 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: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Bruce Momjian <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> I thought the consensus of the discussion was that this was not >>> necessary. It sure doesn't strike me as a good idea. > Also, keep in mind that in the end most folks will be building under > MinGW using a release tarball, that has those output files. We haven't > gotten a MinGW release yet, so they have to build all the stuff. Well, that's a fair argument, but why don't you get Marc to set up nightly snapshots for the WIN32_DEV branch? That only costs cycles in the short term. Polluting CVS with updates to derived files will cost us CVS storage forever. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
On Sun, 7 Sep 2003, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> Tom Lane wrote: > >>> I thought the consensus of the discussion was that this was not > >>> necessary. It sure doesn't strike me as a good idea. > > > Also, keep in mind that in the end most folks will be building under > > MinGW using a release tarball, that has those output files. We haven't > > gotten a MinGW release yet, so they have to build all the stuff. > > Well, that's a fair argument, but why don't you get Marc to set up > nightly snapshots for the WIN32_DEV branch? That only costs cycles > in the short term. Polluting CVS with updates to derived files will > cost us CVS storage forever. Easy enough, and done ... ftp://ftp.postgresql.org/pub/win32_dev will have it run nighty like the regular snapshot ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> Tom Lane wrote: > >>> I thought the consensus of the discussion was that this was not > >>> necessary. It sure doesn't strike me as a good idea. > > > Also, keep in mind that in the end most folks will be building under > > MinGW using a release tarball, that has those output files. We haven't > > gotten a MinGW release yet, so they have to build all the stuff. > > Well, that's a fair argument, but why don't you get Marc to set up > nightly snapshots for the WIN32_DEV branch? That only costs cycles > in the short term. Polluting CVS with updates to derived files will > cost us CVS storage forever. Hmm, another problem is that I don't think there is a flex port for MinGW --- at least I remember someone saying they found bison, but not flex, so if they grab the snapshot, they will not be able to use CVS to do development and diffs. -- 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: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Marc G. Fournier wrote: > > > On Sun, 7 Sep 2003, Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > >> Tom Lane wrote: > > >>> I thought the consensus of the discussion was that this was not > > >>> necessary. It sure doesn't strike me as a good idea. > > > > > Also, keep in mind that in the end most folks will be building under > > > MinGW using a release tarball, that has those output files. We haven't > > > gotten a MinGW release yet, so they have to build all the stuff. > > > > Well, that's a fair argument, but why don't you get Marc to set up > > nightly snapshots for the WIN32_DEV branch? That only costs cycles > > in the short term. Polluting CVS with updates to derived files will > > cost us CVS storage forever. > > Easy enough, and done ... > > ftp://ftp.postgresql.org/pub/win32_dev > > will have it run nighty like the regular snapshot Oh, that's nice. I put it on my web site so people don't need CVS installed. -- 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: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Bruce Momjian <[EMAIL PROTECTED]> writes: > Hmm, another problem is that I don't think there is a flex port for > MinGW --- at least I remember someone saying they found bison, but not > flex, so if they grab the snapshot, they will not be able to use CVS to > do development and diffs. So? Supplying the derived files via CVS rather than via snapshots won't improve matters at all for people who haven't got the tools. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Hmm, another problem is that I don't think there is a flex port for > > MinGW --- at least I remember someone saying they found bison, but not > > flex, so if they grab the snapshot, they will not be able to use CVS to > > do development and diffs. > > So? Supplying the derived files via CVS rather than via snapshots > won't improve matters at all for people who haven't got the tools. Why do you need the tools if CVS has the files? I added something to configure so the derived files are newer than the others. -- 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: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
On Sun, 7 Sep 2003, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > >> Tom Lane wrote: > > >>> I thought the consensus of the discussion was that this was not > > >>> necessary. It sure doesn't strike me as a good idea. > > > > > Also, keep in mind that in the end most folks will be building under > > > MinGW using a release tarball, that has those output files. We haven't > > > gotten a MinGW release yet, so they have to build all the stuff. > > > > Well, that's a fair argument, but why don't you get Marc to set up > > nightly snapshots for the WIN32_DEV branch? That only costs cycles > > in the short term. Polluting CVS with updates to derived files will > > cost us CVS storage forever. > > Hmm, another problem is that I don't think there is a flex port for > MinGW --- at least I remember someone saying they found bison, but not > flex, so if they grab the snapshot, they will not be able to use CVS to > do development and diffs. Actually, if I recall that same thread, one person mentioned downloading a MinGW bison port, and then could build flex no problem using that ... Basically, I agree with Tom ... if we are going to go the extra steps to support Win32, at least the Win32 ppl can do is take the extra steps to build using the same 'restrictions' as the Unix ppl go through ... ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Marc G. Fournier wrote: > > Hmm, another problem is that I don't think there is a flex port for > > MinGW --- at least I remember someone saying they found bison, but not > > flex, so if they grab the snapshot, they will not be able to use CVS to > > do development and diffs. > > Actually, if I recall that same thread, one person mentioned downloading a > MinGW bison port, and then could build flex no problem using that ... > > Basically, I agree with Tom ... if we are going to go the extra steps to > support Win32, at least the Win32 ppl can do is take the extra steps to > build using the same 'restrictions' as the Unix ppl go through ... Well, the files are in there now --- I might as well just leave them so they don't have to go through that. This MinGW environment is much more limited than a Unix environment --- no bison, flex, cvs, or perl. Once people are invested in the port, I think they will install those tools, but I like to make the getting-started easier. -- 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: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Marc G. Fournier wrote: > > Hmm, another problem is that I don't think there is a flex port for > > MinGW --- at least I remember someone saying they found bison, but not > > flex, so if they grab the snapshot, they will not be able to use CVS to > > do development and diffs. > > Actually, if I recall that same thread, one person mentioned downloading a > MinGW bison port, and then could build flex no problem using that ... > > Basically, I agree with Tom ... if we are going to go the extra steps to > support Win32, at least the Win32 ppl can do is take the extra steps to > build using the same 'restrictions' as the Unix ppl go through ... Also, those files will not move into main CVS, and no one in Win32 is going to be playing with changing any of the source files used by bison/flex. -- 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: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> So? Supplying the derived files via CVS rather than via snapshots >> won't improve matters at all for people who haven't got the tools. > Why do you need the tools if CVS has the files? Why do you need the tools if the nightly snapshots have the files? Same either way AFAICS. My objection is basically that CVS is a hugely inefficient mechanism for delivering derived files. The cost is about the same from a downloader's point of view as snapshot tarballs --- but we pay for each update *forever* in CVS storage. I do not mind having CVS permanently record every feature addition or bug fix; that's potentially-useful history. But there is zero historical content in derived files. > I added something to configure so the derived files are newer than the > others. Doesn't that break the scenario you were just citing where a WIN32_DEV user is trying to fix something in a .y or .l file? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [COMMITTERS] pgsql-server/src backend/bootstrap/Tag: backen ...
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> So? Supplying the derived files via CVS rather than via snapshots > >> won't improve matters at all for people who haven't got the tools. > > > Why do you need the tools if CVS has the files? > > Why do you need the tools if the nightly snapshots have the files? > Same either way AFAICS. > > My objection is basically that CVS is a hugely inefficient mechanism > for delivering derived files. The cost is about the same from a > downloader's point of view as snapshot tarballs --- but we pay for each > update *forever* in CVS storage. I do not mind having CVS permanently > record every feature addition or bug fix; that's potentially-useful > history. But there is zero historical content in derived files. Oh, that's true. Maybe I should just push the snapshots because those are easier, and cvs isn't even in MinGW. I mount a Unix directory for builds, so I have CVS and all the other tools. Once nice thing about CVS is that you don't have to download the whole tarball each time --- good for code in development like MinGW. Also, one thing I am doing is pushing HEAD changes down in to the branch so I get the HEAD Win32 fixes that go in, and merging will be easier. Isn't that going to make overhead too? > > I added something to configure so the derived files are newer than the > > others. > > Doesn't that break the scenario you were just citing where a WIN32_DEV > user is trying to fix something in a .y or .l file? Sure. I don't anticipate any changes made there. All the stuff left is backend startup stuff. -- 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
[COMMITTERS] pgsql-server/. Tag: WIN32_DEV UPDATED
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/08 01:24:01 Added files: . : Tag: WIN32_DEV UPDATED Log message: List derived files. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
