Re: [HACKERS] url for TODO item, is it right?
Michael Fuhr [EMAIL PROTECTED] writes: On Mon, Jul 17, 2006 at 12:25:09AM -0500, Jaime Casanova wrote: i found this on the Monitoring section: o Allow protocol-level BIND parameter values to be logged http://archives.postgresql.org/pgsql-hackers/2006-02/msg00165.php But i don't understand why that thread is related to the TODO item, i'm missing something? Possibly the message renumbering that Tom griped about: http://archives.postgresql.org/pgsql-www/2006-07/msg00061.php Yeah. I think the TODO item is intended to point to what is now http://archives.postgresql.org/pgsql-hackers/2006-02/msg00163.php or one of the earlier messages in that thread. Perhaps when Bruce realizes he needs to recheck every link in the TODO files, he'll get on the warpath with me ;-) regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] unsubscribe
unsubscribe ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plPHP and plRuby
Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake: We were going to submit plPHP to core for inclusion but it is not ready yet. Is there enough interest in plRuby to get it where it needs to be for possible inclusion into core? Considering that PL/Java effectively just got shot down, I don't see any hope for these. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features?
Am Freitag, den 14.07.2006, 16:26 +0200 schrieb Bernd Helmle: --On Freitag, Juli 14, 2006 01:23:11 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: . multiple values clauses for INSERT Susanne Ebrecht [EMAIL PROTECTED] was last heard to work on it. Updates, Susanne? I've talked to Susanne today and she's just back from hospital and not available online until next week. She was working on the SET (col1, col2) = (val1, val2) syntax for UPDATE commands. Don't know what the status is on this, though. Thanks Peter and Bernd for your postings. I'am working on update table set (col1, col2, ...) = (val1, val2, ...), (colx, coly, ...) = (valx, valy, ...), ... I hope, it will be finished this week. Most of work is done. Susanne signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [HACKERS] automatic system info tool?
On Sun, Jul 16, 2006 at 06:49:26PM -0400, Andrew Dunstan wrote: We also classify buildfarm machines by os, os_version, compiler, compiler_version and config.guess doesn't give us that, unfortunately. It would seem to be a lot easier to use the values from perl itself, given you're already using it: # perl -MConfig -e 'print os=$Config{osname}, osvers=$Config{osvers}, archname=$Config{archname}\n' os=linux, osvers=2.6.15.4, archname=i486-linux-gnu-thread-multi If you look at perl -V it give you a subset of useful values, probably a lot nicer than munging config.guess. It'll even tell you the size of of the C datatypes if you're interested :) Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] url for TODO item, is it right?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://archives.postgresql.org/pgsql-www/2006-07/msg00061.php Yeah. I think the TODO item is intended to point to what is now http://archives.postgresql.org/pgsql-hackers/2006-02/msg00163.php or one of the earlier messages in that thread. This is a very ugly problem. Note that there are also URLs that cannot be changed, such as older messages that point to archive posts, and many places on the web outside of our control. Why can't we just write a script that creates new numbers as needed, such as msg00163.1.php and msg00163.2.php? As far as I can tell, there is nothing magical about the naming schema itself that would cause such URLs to break anything. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200607170743 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFEu3iovJuQZxSWSsgRAqafAKD51/vpiZnDkHyCQ2TrPkPEXPUQbwCfVRux 5Rw14QzglcYed2A54IGtKrc= =hz49 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] plpython sets
Hello all, I'm working with pl/python and I'd like to use the set returning function feature. I'm not working in a debug python, so the iterator bug is not a problem me. Can someone point me to some plpython.c setof enabled sources? Hint to build them in an ubuntu dapper environment are welcome too :-P ! Thanks a lot every developer involved in postgres! PL/setyourlanguagehere is fantastic! Matteo Bertini begin:vcard fn:Matteo Bertini n:Bertini;Matteo email;internet:[EMAIL PROTECTED] tel;cell:+39(0)3284729474 note;quoted-printable:Ci sono 10 tipi di persone, quelle che capiscono il Binario e quelle chen= on lo capiscono.=0D=0A= OpenPGP: http://blog.naufraghi.net/openpgp=0D=0A= ICQ: 33956256 url:http://www.slug.it/naufraghi/ version:2.1 end:vcard ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Continuous dataflow streaming
Hello What are the possibilities (if any) for continuous dataflow streaming with PostgreSQL v.8.1 ? Something like TelegraphCQ project,but it was for v.7.3.Is there any alternatives for the latest version of PostgreSQL ? Sincerely -- Dragan Zubac
Re: [HACKERS] automatic system info tool?
I'm fairly familiar with it :-) The trouble is that it gives info set at the time perl was compiled, which doesn't help with the problem where a machine has been upgraded. For example, on this FC3 machine it reports a different kernel version from the one I have upgraded to, not surprisingly. So what I need if possible is a runtime tool to detect the info we need. cheers andrew Martijn van Oosterhout wrote: On Sun, Jul 16, 2006 at 06:49:26PM -0400, Andrew Dunstan wrote: We also classify buildfarm machines by os, os_version, compiler, compiler_version and config.guess doesn't give us that, unfortunately. It would seem to be a lot easier to use the values from perl itself, given you're already using it: # perl -MConfig -e 'print os=$Config{osname}, osvers=$Config{osvers}, archname=$Config{archname}\n' os=linux, osvers=2.6.15.4, archname=i486-linux-gnu-thread-multi If you look at perl -V it give you a subset of useful values, probably a lot nicer than munging config.guess. It'll even tell you the size of of the C datatypes if you're interested :) Have a nice day, ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] plPHP and plRuby
Peter Eisentraut wrote: Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake: We were going to submit plPHP to core for inclusion but it is not ready yet. Is there enough interest in plRuby to get it where it needs to be for possible inclusion into core? Considering that PL/Java effectively just got shot down, I don't see any hope for these. But the reasons that applied to PL/Java (masses of non-C code was the main one) probably don't apply in these 2 cases. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] automatic system info tool?
On Mon, Jul 17, 2006 at 09:06:34AM -0400, Andrew Dunstan wrote: I'm fairly familiar with it :-) The trouble is that it gives info set at the time perl was compiled, which doesn't help with the problem where a machine has been upgraded. For example, on this FC3 machine it reports a different kernel version from the one I have upgraded to, not surprisingly. Hmm. The osname and archname might still be useful, but the rest could be out of date. So what I need if possible is a runtime tool to detect the info we need. On UNIX systems uname may work pretty well. But I guess each system may have slightly different options. What'll probably happen is that you end up with a big if() statement testing $Config{osname} wtih each case having specific code to determine the specifics. But for that you need information. How do you get the currently running release of windows for example? Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] plPHP and plRuby
Peter Eisentraut wrote: Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake: We were going to submit plPHP to core for inclusion but it is not ready yet. Is there enough interest in plRuby to get it where it needs to be for possible inclusion into core? Considering that PL/Java effectively just got shot down, I don't see any hope for these. PLRuby is written in C. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] automatic system info tool?
On UNIX systems uname may work pretty well. But I guess each system may have slightly different options. What'll probably happen is that you end up with a big if() statement testing $Config{osname} wtih each case having specific code to determine the specifics. But for that you need information. How do you get the currently running release of windows for example? If you can open a command shell you can get the OS version with the 'ver' command under Windows: C:\ver Microsoft Windows XP [Version 5.1.2600] C:\ This should work on 2000 or later. (Windows 2000 is 5.0.something.) Regards, Paul ---(end of broadcast)--- TIP 1: 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] plPHP and plRuby
Andrew Dunstan wrote: But the reasons that applied to PL/Java (masses of non-C code was the main one) probably don't apply in these 2 cases. I don't think it's the amount of non-C code; it's the amount of code that no one understands. Plus, an argument *for* inclusion was build farm coverage, which I understand will be solved in a different way, applicable to all external modules. Another argument was buzzword compliance, which doesn't apply to these two new candidates. So in summary, while I have not seen any valid reason for these inclusions, there continue to be some against it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plPHP and plRuby
Joshua D. Drake wrote: PLRuby is written in C. Specifically on the matter of PL/Ruby -- and if you're trying to be such an advocate about it, you should at least spell it right -- I have never seen the author particularly active within this community, so I have my doubts whether the development processes will integrate well. In fact, shouldn't the inclusion request come from the author in the first place? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: 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] plPHP and plRuby
Peter Eisentraut wrote: Andrew Dunstan wrote: But the reasons that applied to PL/Java (masses of non-C code was the main one) probably don't apply in these 2 cases. I don't think it's the amount of non-C code; it's the amount of code that no one understands. Plus, an argument *for* inclusion was build farm coverage, which I understand will be solved in a different way, applicable to all external modules. Another argument was buzzword compliance, which doesn't apply to these two new candidates. So in summary, while I have not seen any valid reason for these inclusions, there continue to be some against it. Ahh o.k. not to be argumentative but PHP is huge and RUby gets more then it fair share of press and articles written about it now. Alot of those *enterprises* that used to use Java are migrating to PHP (why I really don't know but that isn't the point). That being said, PLphp is currently a no-op and won't be able to be considered for 8.2 due to portability issues. However PLruby is a valid inclusion and would enhance our portfolio of pl languages nicely. PLruby also has the benefit of not being repulsive to Perl or Python programmers (where is many perl and python guys really don't like the other ;)). Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] plPHP and plRuby
Peter Eisentraut wrote: Joshua D. Drake wrote: PLRuby is written in C. Specifically on the matter of PL/Ruby -- and if you're trying to be such an advocate about it, you should at least spell it right -- I have never seen the author particularly active within this community, so I have my doubts whether the development processes will integrate well. In fact, shouldn't the inclusion request come from the author in the first place? That is a good point. However in this case, it was CMD that worked with the Author to change the license, specifically for this case. I don't think the author really had any intent of submitting it until we approached him. From a personal perspective, I do not care if we include PL/Ruby. I don't use Ruby. I am a Python guy. However I know a lot of Ruby folk that use PostgreSQL. This would be a good way to improve the native Ruby support for PostgreSQL. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] plPHP and plRuby
Peter Eisentraut wrote: Andrew Dunstan wrote: But the reasons that applied to PL/Java (masses of non-C code was the main one) probably don't apply in these 2 cases. I don't think it's the amount of non-C code; it's the amount of code that no one understands. Plus, an argument *for* inclusion was build farm coverage, which I understand will be solved in a different way, applicable to all external modules. Another argument was buzzword compliance, which doesn't apply to these two new candidates. So in summary, while I have not seen any valid reason for these inclusions, there continue to be some against it. Well, I am not making any promises right now about when buildfarm will support external modules. My current thinking goes something like this: . the config file will contain an extra stanza looking something like this: addons = { addonname = { cvsrepo = repo locn, module= modulename } ... } . addons will be checked out at the same time as the core, but into a separate directory. We will check them for recent mods in the same way as the core. . after we run make installcheck for the core we will run make for each addon using the installed pgxs. . after we run make installcheck for contrib we will run make installcheck for each addon. (Question - do we restrict addons to those that will build using pgxs?) Happily, most of the webapp is agnostic about what is reported on - probably adding one db field containing the addon names for the build would suffice. There are some odd wrinkles. For instance, construction of the URLs for changed files will be somewhat harder. For that reason I think I am going to insist at least in the first instance that all addons must be hosted on pgfoundry where we know perfectly well how to construct cvsweb URLs.There will undoubtedly be more when I get down to it. And we might need to ignore addons for builds on stable branches up to and including 8.2 - I don't know yet. Now, if someone feels like taking those ideas and running with them in the buildfarm client code they are welcome to drop me a line and I can add them to the project as a developer. Otherwise it will have to wait till I get around to it. That's likely to be some way well into the 8.3 development cycle at the earliest. And lastly, if we are not going to include these in core, I repeat what I said before: we need to undertake some *serious* evangelising to major packagers to get them to build more than just the core among their standard packages. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plPHP and plRuby
And lastly, if we are not going to include these in core, I repeat what I said before: we need to undertake some *serious* evangelising to major packagers to get them to build more than just the core among their standard packages. Andrew I keep seeing this, but what major packagers are we talking about? Actually as I look at this, the only major distribution (that is not commercial) that doesn't support a lot of PostgreSQL packages is Fedora. Ubuntu Debian Gentoo FreeBSD All have a ton of packages (including plruby). Sincerely, Joshua D. Drake cheers andrew -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Continuous dataflow streaming
Dragan, What are the possibilities (if any) for continuous dataflow streaming with PostgreSQL v.8.1 ? Something like TelegraphCQ project,but it was for v.7.3.Is there any alternatives for the latest version of PostgreSQL ? The TelegraphCQ team has stopped public development. So it's pretty much waiting for someone to take on their code. FWIW, the existing version of TCQ never solved the not crashing problem, let alone integration with transactional tables. --Josh ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] plPHP and plRuby
Peter, I don't think it's the amount of non-C code; it's the amount of code that no one understands. Plus, an argument *for* inclusion was build farm coverage, which I understand will be solved in a different way, applicable to all external modules. Another argument was buzzword compliance, which doesn't apply to these two new candidates. So in summary, while I have not seen any valid reason for these inclusions, there continue to be some against it. The main reason for including PL/Ruby is that by whatever accident the Ruby community is tending to choose PostgreSQL as their SQL-RDBMS of choice. This is a tendency we'd like to encourage, and one way to do so is to attract Ruby developers to the idea of putting Ruby logic into the database. This also might have the effect of getting more Rails developers to learn about real database architecture. Secondly, I've been told Ruby has some nice features as a language that make it a useful edition to our stable of procedural languages. Hopefully the Ruby aficiandos will speak up an enumerate these. On the other hand, if we include PL/Perl, Tcl and Python but exclude Ruby from the main package we are effectively making a statement to Ruby users that their language is inferior in our consideration. And, as Andrew said, Buildfarm External Modules are not going to be added next month. However, the lack of a maintainer who is an active participant in the community is a serious drawback ... probably even a fatal one. Josh, is there a reason why the PL/Ruby hacker doesn't want to play with us? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] plPHP and plRuby
However, the lack of a maintainer who is an active participant in the community is a serious drawback ... probably even a fatal one. Josh, is there a reason why the PL/Ruby hacker doesn't want to play with us? I don't think it is, doesn't want to play with us. I think he just doesn't :). That being said, we may want to check and see if he participates in PostgreSQLFR (he is french). Also note, that if it were included, CMD would dedicate resources to help keeping it stable etc... Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] plPHP and plRuby
On Mon, 2006-07-17 at 10:11 -0700, Josh Berkus wrote: On the other hand, if we include PL/Perl, Tcl and Python but exclude Ruby from the main package we are effectively making a statement to Ruby users that their language is inferior in our consideration. Hardly -- no more so than not including JDBC and PL/Java in the main CVS is evidence that we're all Java haters. The fact that we include PL/Perl, PL/Python and PL/Tcl is more a matter of momentum/historical accident than an expression of preference, IMHO. However, the lack of a maintainer who is an active participant in the community is a serious drawback Well, if the author is interested in maintaining PL/Ruby as part of the postgresql.org CVS tree (is he?), I think that is sufficient. Whether he participates in the community beyond maintaining PL/Ruby is not really relevant, IMHO. (FWIW, I'd be fairly comfortable hacking on PL/Ruby, as I have some prior experience with Ruby and its C API.) -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Proposed patch for contrib/cube
Hi, I use the cube datatype a fair bit, and one thing I have always wanted is the ability to do this: pg=# select cube_from_arrays('{1,2,3}'::float[], '{3,5,6}'::float[]); cube_from_arrays - (1, 2, 3),(3, 5, 6) (1 row) That is - build a cube by specifying 2 arrays, one for the UR coordinate, one for LL. I hope people find this useful, and if so, we can add it to contrib/cube. Source is attached. Thanks, Joshua Reich (jdigittl on #postgresql) #include postgres.h #include utils/array.h #include cubedata.h /* contrib/cube */ /* ** CREATE OR REPLACE FUNCTION cube_from_arrays(float[], float[]) RETURNS cube ** AS 'ordermatch' ** LANGUAGE C; */ NDBOX *cube_from_arrays (ArrayType *ur, ArrayType *ll); /* ** Taken from the intarray contrib header */ #define ARRPTR(x) ( (double *) ARR_DATA_PTR(x) ) #define ARRNELEMS(x) ArrayGetNItems( ARR_NDIM(x), ARR_DIMS(x)) /* ** Allows the construction of a cube from 2 float[]'s */ NDBOX *cube_from_arrays (ArrayType *ur, ArrayType *ll) { int i; int dim; int size; NDBOX *result; double *dur, *dll; dim = ARRNELEMS(ur); if (ARRNELEMS(ll) dim) { /* ** If the array's are not of equal length, use the length ** of the shorter array. */ dim = ARRNELEMS(ll); } dur = ARRPTR(ur); dll = ARRPTR(ll); size = offsetof(NDBOX, x[0]) + sizeof(double) * 2 * dim; result = (NDBOX *) palloc (size); memset (result, 0, size); result-size = size; result-dim = dim; for (i=0; idim; i++) { result-x[i] = dur[i]; result-x[i+dim] = dll[i]; } return result; } ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposed patch for contrib/cube
Joshua Reich [EMAIL PROTECTED] writes: ... build a cube by specifying 2 arrays, one for the UR coordinate, one for LL. I hope people find this useful, and if so, we can add it to contrib/cube. Seems useful, but it needs work: it will fail on toasted arrays or arrays containing nulls. I'd suggest converting it to V1 call protocol too, as the V1 GETARG macros are the easiest answer to the toasting problem. Null array elements are a new issue in CVS HEAD, you'd need to test against HEAD for that. As a matter of style, would it be better to error out if the arrays are not the same length? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Possible explanation for Win32 stats regression test
Ah-hah, I see it. pgwin32_select() uses WaitForMultipleObjectsEx() with an event for the socket read-ready plus an event for signal arrival. It returns EINTR if the return code from WaitForMultipleObjectsEx shows the signal-arrival event as fired. However, WaitForMultipleObjectsEx is defined to return the number of the *first* event in the list that is fired. This means that if the socket comes read-ready at the same time the SIGALRM arrives, pgwin32_select() will ignore the signal, and it'll be processed by the subsequent pgwin32_recv(). Now I don't know anything about the Windows scheduler, but I suppose it gives processes time quantums like everybody else does. So at the same time really means within the same scheduler clock tick, which is not so unlikely after all. In short, before the just-committed patch, the Windows stats collector would fail if a stats message arrived during the same clock tick that its SIGALRM timeout expired. I think this explains not only the intermittent stats regression failures, but the reports we've heard from Merlin and others about the stats collector being unstable under load on Windows. The heavier the load of stats messages, the more likely one is to arrive during the tick when the timeout expires. There's a second problem in pgwin32_waitforsinglesocket() that may be getting in your way. Inside of pgwin32_waitforsingleselect(), we create a kernel synchronization object (an Event) and associate that Event with the socket. When the TCP/IP stack detects interesting traffic on the socket, it signals the Event object (interesting in this case is READ, WRITE, CLOSE, or ACCEPT, depending on the caller) and that wakes up the call to WaitForMultipleObjectsEx(). That all works fine, unless you have two or more sockets in the backend (the important part is that src/include/port/win32.h #define's select() and other socket-related function - if you compile a piece of network code that happens to #include port/win32.h, you'll get the pgwin32_xxx() versions). The problem is that, each time you go through pgwin32_waitforsinglesocket(), you tie the *same* kernel object (waitevent is static) to each socket. If you have more than one socket, you'll tie each socket to the same kernel event. The kernel will signal that Event whenever interesting traffic appears on *any* of the sockets. The net effect is that, if you are waiting for activity on socket A, any activity on socket B will also awaken WaitForMultipleObjects(). If you then try to read from socket A, you'll get an operation would block error because nothing happened on socket A. The fix is pretty simple - just call WSAEventSelect( s, waitevent, 0 ) after WaitForMultipleObjectsEx() returns. That disassociates the socket from the Event (it will get re-associated the next time pgwin32_waitforsingleselect() is called. I ran into this problem working on the PL/pgSQL debugger and I haven't gotten around to posting a patch yet, sorry. -- Korry ([EMAIL PROTECTED])
[HACKERS] TODO: Mark change-on-restart-only values in postgresql.conf
I would like to implement Mark change-on-restart-only values in postgresql.conf item. Anybody works on this? Does it mean add extra comment to postgresql.conf for variable which has PG_POSTMASTER context? Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO: Mark change-on-restart-only values in postgresql.conf
Zdenek, I would like to implement Mark change-on-restart-only values in postgresql.conf item. Anybody works on this? Does it mean add extra comment to postgresql.conf for variable which has PG_POSTMASTER context? Somehow I thought you'd already submitted a patch? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plPHP and plRuby
Neil, (FWIW, I'd be fairly comfortable hacking on PL/Ruby, as I have some prior experience with Ruby and its C API.) Well, if you're willing to be a maintainer, that removes a major roadblock. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] src/tools/pginclude considered harmful (was Re:
FYI, I updated pginclude/README to explain the complexity of removing includes from include files: pgfixinclude sort include references run multiple times: pgcompinclude pgrminclude /src/include pgrminclude / pgcheckdefines There is a complexity when modifying /src/include. If include file 1 includes file 2, and file 2 includes file 3, then when file 1 is processed, it needs only file 2, not file 3. However, if later, include file 2 is processed, and file 3 is not needed by file 2 and is removed, file 1 might then need to include file 3. For this reason, the pgcompinclude and pgrminclude /src/include steps must be run several times until all includes compile cleanly. I followed this process, but didn't full understand why multiple include runs were necessary until I thought about it. FYI, 527 include were removed from non-header C files in this run. That is not something that can be easily done manually. --- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I agree with reverting. The tool looks pretty broken anyway, with hardcoded paths and all sorts of stuff quite apart from logic problems. Well, it's only intended to work on Bruce's system, so until someone else takes over the position of chief gruntwork-doer I don't think the portability issues are much of a factor. What I'm worried about at the moment is the correctness issue. After some reflection it seems that there is only one case where removal of a needed include file would not lead to a compiler error or warning, assuming gcc with ordinary -W settings (notably -Wmissing-prototypes). That case is exactly what Kris found: removal of a #define that is tested via #ifdef or #if defined(). (Can anyone think of other cases?) It's not hard to imagine getting burnt by this through ordinary manual rearrangement or cleanup of inclusions, so I'm thinking that blaming pgrminclude may be too hasty. It'd be worth our time to make a tool to check for it. I'm going to work on a Perl script that sucks up all the #defines in all our .h files and looks for #ifdef foo or defined foo where foo is defined in a file not included by the referencing file (gcc -H looks like the right tool for checking that). Another thing such a script could easily do is check for inclusion of system headers before c.h. regards, tom lane -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO: Mark change-on-restart-only values in
Josh Berkus wrote: Zdenek, I would like to implement Mark change-on-restart-only values in postgresql.conf item. Anybody works on this? Does it mean add extra comment to postgresql.conf for variable which has PG_POSTMASTER context? Somehow I thought you'd already submitted a patch? I sent patch for relatively related problem when somebody commenting out item in the configuration file. This item is look like easy, but I surprise that this item does not have % prefix. The question is if it is only about adding extra comments to postgresql.conf file. Zdenek ---(end of broadcast)--- TIP 1: 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] automatic system info tool?
On Mon, Jul 17, 2006 at 11:06:50AM -0400, Bort, Paul wrote: If you can open a command shell you can get the OS version with the 'ver' command under Windows: C:\ver Microsoft Windows XP [Version 5.1.2600] How do you do this from a program though. Under UNIX uname() is a function call as well as a program. It returns the os name, version, hostname and system type. Mind you, maybe perl provides emulation for uname? Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] plPHP and plRuby
On Mon, Jul 17, 2006 at 12:18:46PM -0400, Andrew Dunstan wrote: Well, I am not making any promises right now about when buildfarm will support external modules. I've been playing with the idea of having a subdirectory named extras with descriptor files describing how to fetch a project and compile it. I got the fetching and the unpacking going, but the building isn't there yet. Still, it's an interesting idea... And lastly, if we are not going to include these in core, I repeat what I said before: we need to undertake some *serious* evangelising to major packagers to get them to build more than just the core among their standard packages. Ack. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] automatic system info tool?
On Jul 17, 2006, at 12:57 PM, Martijn van Oosterhout wrote: On Mon, Jul 17, 2006 at 11:06:50AM -0400, Bort, Paul wrote: If you can open a command shell you can get the OS version with the 'ver' command under Windows: C:\ver Microsoft Windows XP [Version 5.1.2600] How do you do this from a program though. Under UNIX uname() is a function call as well as a program. It returns the os name, version, hostname and system type. GetVersionEx() will get you the windows version, service pack, etc IIRC. Cheers, Steve ---(end of broadcast)--- TIP 1: 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] Proposed patch for contrib/cube
Tom: Thanks for the out-of-band posting to the documentation. I think the new version (attached) addresses your issues. What is the general process for submitting patches? Is there a URL someone can point me towards to learn more? Thanks, Josh Reich Tom Lane wrote: Joshua Reich [EMAIL PROTECTED] writes: ... build a cube by specifying 2 arrays, one for the UR coordinate, one for LL. I hope people find this useful, and if so, we can add it to contrib/cube. Seems useful, but it needs work: it will fail on toasted arrays or arrays containing nulls. I'd suggest converting it to V1 call protocol too, as the V1 GETARG macros are the easiest answer to the toasting problem. Null array elements are a new issue in CVS HEAD, you'd need to test against HEAD for that. As a matter of style, would it be better to error out if the arrays are not the same length? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org #include postgres.h #include utils/array.h #include cubedata.h /* contrib/cube */ #include fmgr.h /* ** CREATE OR REPLACE FUNCTION cube_from_arrays(float[], float[]) RETURNS cube ** AS 'cube_from_arrays' ** LANGUAGE C; */ /* ** Taken from the intarray contrib header */ #define ARRPTR(x) ( (double *) ARR_DATA_PTR(x) ) #define ARRNELEMS(x) ArrayGetNItems( ARR_NDIM(x), ARR_DIMS(x)) /* ** Allows the construction of a cube from 2 float[]'s */ PG_FUNCTION_INFO_V1(cube_from_arrays); NDBOX * cube_from_arrays (PG_FUNCTION_ARGS) { int i; int dim; int size; NDBOX *result; ArrayType *ur, *ll; double *dur, *dll; if (PG_ARGISNULL(0) || PG_ARGISNULL(1)) { ereport(ERROR, (errcode(ERRCODE_ARRAY_ELEMENT_ERROR), errmsg(Cannot work with NULL arrays))); } ur = (ArrayType *) PG_GETARG_VARLENA_P(0); ll = (ArrayType *) PG_GETARG_VARLENA_P(1); dim = ARRNELEMS(ur); if (ARRNELEMS(ll) != dim) { ereport(ERROR, (errcode(ERRCODE_ARRAY_ELEMENT_ERROR), errmsg(UR and LL arrays must be of same length))); PG_RETURN_NULL(); } dur = ARRPTR(ur); dll = ARRPTR(ll); size = offsetof(NDBOX, x[0]) + sizeof(double) * 2 * dim; result = (NDBOX *) palloc (size); memset (result, 0, size); result-size = size; result-dim = dim; for (i=0; idim; i++) { result-x[i] = dur[i]; result-x[i+dim] = dll[i]; } PG_RETURN_DATUM(result); } ---(end of broadcast)--- TIP 1: 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] plpython sets
Matteo Bertini wrote: Hello all, I'm working with pl/python and I'd like to use the set returning function feature. I'm not working in a debug python, so the iterator bug is not a problem me. Can someone point me to some plpython.c setof enabled sources? Hint to build them in an ubuntu dapper environment are welcome too :-P ! Thanks a lot every developer involved in postgres! PL/setyourlanguagehere is fantastic! http://python.projects.postgresql.org/ This works very well for me - although it needs some more finish (docs and so on) maybe if more people using it it can get better. SRF - even lazy ones (e.g. generators) work nicely there. Regards Tino Wildenhain ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposed patch for contrib/cube
Josh, What is the general process for submitting patches? Is there a URL someone can point me towards to learn more? Send them in an e-mail to pgsql-patches. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] automatic system info tool?
How do you do this from a program though. Under UNIX uname() is a function call as well as a program. It returns the os name, version, hostname and system type. Multiple methods (TIMTOWTDI) depending on what you want: my $verstring = `cmd.exe /c ver`; # or use Win32; my ($string, $major, $minor, $build, $id ) = Win32::GetOSVersion; The environment variables PROCESSOR_ARCHITECTURE and PROCESSOR_IDENTIFIER should provide the basic hardware information. Mind you, maybe perl provides emulation for uname? Not that I know of. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pg_dump: add option to ignore TABLE DATA for failed TABLE object creation
Hi PostgreSQL developers, some time ago I started a discussion [1] here about modifying pg_dump to not restore TABLE DATA objects if the corresponding TABLE oject failed to be created (usually because it already exists, but it might fail due to a different error like a nonexisting data type). We need this to provide automatic major version upgrades for databases with extensions like PostGIS. Tom's reply [3] seemed to indicate that this was not entirely crackful, so I implemented his approach, and after some feedback I now have a fairly clean patch that works very well. The patch was scheduled for review and inclusion [4], and indeed the page had the patch for a while, but after some time it vanished. Can you please reconsider this? If there is still a problem with the patch, I'd like to work on it until it meets your standards. For your convenience I attach the current patch version; a test script [5] is also available (the ML kills shell script attachments, so I put it on a Debian server). It does not alter the default behaviour, it just adds a new option -X no-data-for-failed-tables. If you think this mode should be the default, I'm happy to change it that way. Thank you a lot! Martin [1] http://archives.postgresql.org/pgsql-hackers/2006-02/msg00694.php [2] http://bugs.debian.org/351571 [3] http://archives.postgresql.org/pgsql-hackers/2006-02/msg00716.php [4] http://archives.postgresql.org/pgsql-hackers/2006-02/msg01253.php [5] http://people.debian.org/~mpitt/test-pg_restore-existing.sh -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? diff -ruN postgresql-8.1.3-old/doc/src/sgml/ref/pg_restore.sgml postgresql-8.1.3/doc/src/sgml/ref/pg_restore.sgml --- postgresql-8.1.3-old/doc/src/sgml/ref/pg_restore.sgml 2005-11-01 22:09:50.0 +0100 +++ postgresql-8.1.3/doc/src/sgml/ref/pg_restore.sgml 2006-03-03 19:13:50.0 +0100 @@ -395,6 +395,20 @@ /listitem /varlistentry + varlistentry + termoption-X no-data-for-failed-tables//term + listitem + para + By default, table data objects are restored even if the + associated table could not be successfully created (e. g. + because it already exists). With this option, such table + data is silently ignored. This is useful for dumping and + restoring databases with tables which contain auxiliary data + for PostgreSQL extensions (e. g. PostGIS). + /para + /listitem + /varlistentry + /variablelist /para diff -ruN postgresql-8.1.3-old/src/bin/pg_dump/pg_backup_archiver.c postgresql-8.1.3/src/bin/pg_dump/pg_backup_archiver.c --- postgresql-8.1.3-old/src/bin/pg_dump/pg_backup_archiver.c 2006-02-05 21:58:57.0 +0100 +++ postgresql-8.1.3/src/bin/pg_dump/pg_backup_archiver.c 2006-03-03 19:14:03.0 +0100 @@ -268,6 +268,23 @@ _printTocEntry(AH, te, ropt, false, false); defnDumped = true; + /* If we could not create a table, ignore the respective TABLE DATA if +* -X no-data-for-failed-tables is given */ + if (ropt-noDataForFailedTables AH-lastErrorTE == te strcmp (te-desc, TABLE) == 0) { + TocEntry *tes, *last; + + ahlog (AH, 1, table %s could not be created, will not restore its data\n, te-tag); + + for (last = te, tes = te-next; tes != AH-toc; last = tes, tes = tes-next) { + if (strcmp (tes-desc, TABLE DATA) == 0 strcmp (tes-tag, te-tag) == 0 + strcmp (tes-namespace ? tes-namespace : , te-namespace ? te-namespace : ) == 0) { + /* remove this node */ + last-next = tes-next; +break; + } + } + } + /* If we created a DB, connect to it... */ if (strcmp(te-desc, DATABASE) == 0) { diff -ruN postgresql-8.1.3-old/src/bin/pg_dump/pg_backup.h postgresql-8.1.3/src/bin/pg_dump/pg_backup.h --- postgresql-8.1.3-old/src/bin/pg_dump/pg_backup.h2005-10-15 04:49:38.0 +0200 +++ postgresql-8.1.3/src/bin/pg_dump/pg_backup.h2006-03-03 19:13:50.0 +0100 @@ -106,6 +106,7 @@ char *pghost; char *username; int ignoreVersion; + int noDataForFailedTables; int requirePassword; int exit_on_error; diff -ruN
Re: [HACKERS] Possible explanation for Win32 stats regression test
korry [EMAIL PROTECTED] writes: The problem is that, each time you go through pgwin32_waitforsinglesocket(), you tie the *same* kernel object (waitevent is static) to each socket. The fix is pretty simple - just call WSAEventSelect( s, waitevent, 0 ) after WaitForMultipleObjectsEx() returns. That disassociates the socket from the Event (it will get re-associated the next time pgwin32_waitforsingleselect() is called. Hmm. Presumably we don't do this a whole lot (use multiple sockets) or we'd have noticed before. Perhaps better would be to keep an additional static variable saying which socket the event is currently associated to, and only issue the extra WSAEventSelect calls if we need to change it. Or is WSAEventSelect fast enough that it doesn't matter? Anyway, someone with a Windows machine needs to code and test this ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features?
Andrew Dunstan wrote: Bernd Helmle wrote: --On Freitag, Juli 14, 2006 01:23:11 +0200 Peter Eisentraut [EMAIL PROTECTED] wrote: . multiple values clauses for INSERT Susanne Ebrecht [EMAIL PROTECTED] was last heard to work on it. Updates, Susanne? I've talked to Susanne today and she's just back from hospital and not available online until next week. She was working on the SET (col1, col2) = (val1, val2) syntax for UPDATE commands. Don't know what the status is on this, though. Not the same thing, surely. So maybe we should gratefully accept Joe Conway's offer to work on it. I've played with this a bit now, and the grammar changes seem pretty straightforward, but the other half is kind of ugly. I can't see a good way to propagate multiple targetlists that isn't a big hack. The best way might be to fabricate a selectStmt equiv to SELECT targetlist UNION ALL SELECT targetlist..., but that still feels like a hack. Have there been any past discussions on how this might be implemented (FWIW I couldn't find any in the archives)? Any better ideas for an approach? Thanks, Joe ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plpython sets
Ühel kenal päeval, E, 2006-07-17 kell 22:54, kirjutas Tino Wildenhain: Matteo Bertini wrote: Hello all, I'm working with pl/python and I'd like to use the set returning function feature. I'm not working in a debug python, so the iterator bug is not a problem me. Can someone point me to some plpython.c setof enabled sources? Hint to build them in an ubuntu dapper environment are welcome too :-P ! Thanks a lot every developer involved in postgres! PL/setyourlanguagehere is fantastic! http://python.projects.postgresql.org/ This works very well for me - although it needs some more finish (docs and so on) maybe if more people using it it can get better. SRF - even lazy ones (e.g. generators) work nicely there. We at Skype or more precisely Sven Suursoho :) , has added these to the version of plpython in the core and they will be available in 8.2. Code for 8.0 and 8.1 will be available on request, and soon also from https://developer.skype.com/ Enchancements added are: * named parameters (args[] still valid) * returning composite types (dict, tuple, list, class) * returning SETOF as any iterable object (list, tuple, iterator, generator) -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] plPHP and plRuby
Ühel kenal päeval, E, 2006-07-17 kell 22:01, kirjutas Martijn van Oosterhout: On Mon, Jul 17, 2006 at 12:18:46PM -0400, Andrew Dunstan wrote: Well, I am not making any promises right now about when buildfarm will support external modules. I've been playing with the idea of having a subdirectory named extras with descriptor files describing how to fetch a project and compile it. I got the fetching and the unpacking going, but the building isn't there yet. Still, it's an interesting idea... Actually it would be nice to have the not-included PLs present in src/pl/ as their own directories with a README.TXT containing fetch and build instructions So we would have src/pl/plphp/README.TXT src/pl/pljava/README.TXT src/pl/plj/README.TXT and anybody looking for pl-s would find the info in a logical place -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] plPHP and plRuby
On Mon, 17 Jul 2006, Andrew Dunstan wrote: And lastly, if we are not going to include these in core, I repeat what I said before: we need to undertake some *serious* evangelising to major packagers to get them to build more than just the core among their standard packages. Just because an addon is in core (or not) doesn't mean that the packager responsible for building a package for 'the rdbms' is going to bother going into the contrib directory, or any other, to build 'extra stuff' ... In fact, with all of the ppl that lurk on these lists, aren't there enough here that could learn to package for their respective OSs and submit those for inclusion? Or, at least, mentor the various projects maintainers into how to build a package? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plPHP and plRuby
On Tue, 18 Jul 2006, Hannu Krosing wrote: Ühel kenal päeval, E, 2006-07-17 kell 22:01, kirjutas Martijn van Oosterhout: On Mon, Jul 17, 2006 at 12:18:46PM -0400, Andrew Dunstan wrote: Well, I am not making any promises right now about when buildfarm will support external modules. I've been playing with the idea of having a subdirectory named extras with descriptor files describing how to fetch a project and compile it. I got the fetching and the unpacking going, but the building isn't there yet. Still, it's an interesting idea... Actually it would be nice to have the not-included PLs present in src/pl/ as their own directories with a README.TXT containing fetch and build instructions So we would have src/pl/plphp/README.TXT src/pl/pljava/README.TXT src/pl/plj/README.TXT and anybody looking for pl-s would find the info in a logical place *That* idea I like ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 1: 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] [PATCHES] Proposed patch for contrib/cube
Joshua Reich [EMAIL PROTECTED] writes: if (PG_ARGISNULL(0) || PG_ARGISNULL(1)) { ereport(ERROR, (errcode(ERRCODE_ARRAY_ELEMENT_ERROR), errmsg(Cannot work with NULL arrays))); } This is useless code if the function is declared STRICT, as C functions most often are. What you *do* need to be checking is ARR_HASNULL(), since there isn't anything very useful you can do with null elements within the arrays. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] src/tools/pginclude considered harmful (was Re:
Bruce Momjian [EMAIL PROTECTED] writes: FYI, 527 include were removed from non-header C files in this run. That is not something that can be easily done manually. It's not so easily done automatically, either :-(. I'm not sure why this go-round was so much more painful than the last, but it very clearly exposed the deficiencies in your testing process. Mainly, that you tested only one set of configure options on one platform. I would say that minimum requirements for doing this again in future are (1) test with and without --enable-cassert, and (2) test with and without EXEC_BACKEND. We *know* that both those things change the set of headers required. It might be necessary to actually test the WIN32 port separately --- EXEC_BACKEND is close but not the same. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] pg_regress in C
Magnus Hagander [EMAIL PROTECTED] writes: Per discussion at the conference: In order to run the regression tests on Windows without msys, pg_regress needs to be reimplemnted in C. This has some minor portability issues (macros with ... aren't portable, for instance) but I think it's something we need to do. Barring objections I'm going to clean up and apply it. regards, tom lane ---(end of broadcast)--- TIP 1: 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] How portable are the POSIX.2 regular expression routines?
Anyone have an opinion on the portability of the regular expression functions defined in POSIX 1003.2, http://www.opengroup.org/onlinepubs/007908799/xsh/regcomp.html ? In particular, do you know of any platforms we support that don't have them? The reason I'm asking is that to convert pg_regress into C code we need some regex functionality, and the easiest way to get that would be to assume that the C library has it ;-). In Magnus's draft patch he assumed that we could link src/backend/regex/* into pg_regress, but I think that's a really bad way to go. Even though that code is mostly independent of the rest of the backend at the moment, it seems highly unlikely that we'll keep it so forever --- regc_locale.c in particular needs to tie into whatever solution we wind up using for general locale support. Plan B would be to kluge up some quick-and-dirty code to handle just the small subset of regex syntax that we actually use in resultmap ... regards, tom lane ---(end of broadcast)--- TIP 1: 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] How portable are the POSIX.2 regular expression routines?
Tom Lane wrote: Anyone have an opinion on the portability of the regular expression functions defined in POSIX 1003.2, http://www.opengroup.org/onlinepubs/007908799/xsh/regcomp.html ? In particular, do you know of any platforms we support that don't have them? The reason I'm asking is that to convert pg_regress into C code we need some regex functionality, and the easiest way to get that would be to assume that the C library has it ;-). In Magnus's draft patch he assumed that we could link src/backend/regex/* into pg_regress, but I think that's a really bad way to go. Even though that code is mostly independent of the rest of the backend at the moment, it seems highly unlikely that we'll keep it so forever --- regc_locale.c in particular needs to tie into whatever solution we wind up using for general locale support. Plan B would be to kluge up some quick-and-dirty code to handle just the small subset of regex syntax that we actually use in resultmap ... Does Windows come with POSIX regex libs? I would be a bit surprised. When we discussed this at the conference I suggested to Magnus that he not use regexes. When I did initdb I originally looked at using a regex library, and realised that we really wouldn't need them, and the tiny replacement routines I wrote would be sufficient. So I would be tempted to go for Plan B. Plan C might be to assume that we have sed available, just as we are assuming we have diff available. BTW, we I am pretty sure we *do* need MAX_CONNECTIONS it really shouldn't be too hard to implement. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] How portable are the POSIX.2 regular expression routines?
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Anyone have an opinion on the portability of the regular expression functions defined in POSIX 1003.2, Does Windows come with POSIX regex libs? I would be a bit surprised. When we discussed this at the conference I suggested to Magnus that he not use regexes. When I did initdb I originally looked at using a regex library, and realised that we really wouldn't need them, and the tiny replacement routines I wrote would be sufficient. All we really need is something that can handle patterns including .*, because that's all that is used in the patterns in resultmap. That should be doable (inefficiently, but who cares) in just a few lines of code. I'll go for Plan B for the moment. BTW, we I am pretty sure we *do* need MAX_CONNECTIONS it really shouldn't be too hard to implement. Yeah, I thought the same --- you need it on a platform that won't let you run dozens of processes under one userid. Will take care of it. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] How portable are the POSIX.2 regular expression routines?
From: Tom Lane [EMAIL PROTECTED] Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Anyone have an opinion on the portability of the regular expression functions defined in POSIX 1003.2, Does Windows come with POSIX regex libs? I would be a bit surprised. When we discussed this at the conference I suggested to Magnus that he not use regexes. When I did initdb I originally looked at using a regex library, and realised that we really wouldn't need them, and the tiny replacement routines I wrote would be sufficient. +1 for B. I think so too. I covered the logic of Slonik of Slony-I again. It was just for Windows. All we really need is something that can handle patterns including .*, because that's all that is used in the patterns in resultmap. That should be doable (inefficiently, but who cares) in just a few lines of code. I'll go for Plan B for the moment. It is the thing of several lines and being supported will be great, even if it is the limited object. Probably, result will be made equal on all platforms.:-) Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features?
Hello, I did some work on mutliple value insert. First: SELECT .. UNION ALL SELECT is wrong idea. VALUES can contain DEFAULT keyword. Second: It's neccessery general implementation of table values constructor like SQL:2003. Main problem what I see is biger request on sources if we implement MVI as classic PostgreSQL stmt. Regards Pavel Stehule _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings