Re: [HACKERS] url for TODO item, is it right?

2006-07-17 Thread Tom Lane
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

2006-07-17 Thread lawrence . lim
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

2006-07-17 Thread Peter Eisentraut
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?

2006-07-17 Thread Susanne Ebrecht
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?

2006-07-17 Thread Martijn van Oosterhout
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?

2006-07-17 Thread Greg Sabino Mullane

-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

2006-07-17 Thread Matteo Bertini
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

2006-07-17 Thread Dragan Zubac
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?

2006-07-17 Thread Andrew Dunstan


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

2006-07-17 Thread Andrew Dunstan



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?

2006-07-17 Thread Martijn van Oosterhout
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

2006-07-17 Thread Joshua D. Drake

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?

2006-07-17 Thread Bort, Paul
 
 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

2006-07-17 Thread Peter Eisentraut
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

2006-07-17 Thread Peter Eisentraut
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

2006-07-17 Thread Joshua D. Drake

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

2006-07-17 Thread Joshua D. Drake

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

2006-07-17 Thread Andrew Dunstan

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

2006-07-17 Thread Joshua D. Drake




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

2006-07-17 Thread Josh Berkus

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

2006-07-17 Thread Josh Berkus
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

2006-07-17 Thread Joshua D. Drake


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

2006-07-17 Thread Neil Conway
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

2006-07-17 Thread Joshua Reich

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

2006-07-17 Thread Tom Lane
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

2006-07-17 Thread korry







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

2006-07-17 Thread Zdenek Kotala
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

2006-07-17 Thread Josh Berkus
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

2006-07-17 Thread Josh Berkus
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:

2006-07-17 Thread Bruce Momjian

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

2006-07-17 Thread Zdenek Kotala

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?

2006-07-17 Thread Martijn van Oosterhout
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

2006-07-17 Thread 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...

 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?

2006-07-17 Thread Steve Atkins


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

2006-07-17 Thread Joshua Reich
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

2006-07-17 Thread 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.


Regards
Tino Wildenhain

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] Proposed patch for contrib/cube

2006-07-17 Thread Josh Berkus
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?

2006-07-17 Thread Bort, Paul
 
 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

2006-07-17 Thread Martin Pitt
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

2006-07-17 Thread Tom Lane
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?

2006-07-17 Thread Joe Conway

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

2006-07-17 Thread Hannu Krosing
Ü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

2006-07-17 Thread Hannu Krosing
Ü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

2006-07-17 Thread Marc G. Fournier

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

2006-07-17 Thread Marc G. Fournier

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

2006-07-17 Thread Tom Lane
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:

2006-07-17 Thread Tom Lane
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

2006-07-17 Thread Tom Lane
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?

2006-07-17 Thread Tom Lane
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?

2006-07-17 Thread Andrew Dunstan

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?

2006-07-17 Thread Tom Lane
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?

2006-07-17 Thread Hiroshi Saito

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?

2006-07-17 Thread Pavel Stehule

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