Re: [PATCHES] better support of out parameters in plperl

2007-02-08 Thread Bruce Momjian

Would someone review this.  It is in the patches_hold queue:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---

Andrew Dunstan wrote:
 
 I think it has to wait to 8.3. It's a complete mess that was submitted 
 unheralded at the last moment. Pavel needs to get into the habit of 
 submitting ideas first, not just patches. And there must be proper 
 documentation and working regression tests.
 
 cheers
 
 andrew
 
 Bruce Momjian wrote:
  Uh, were are we in fixing/reviewing this?
 
  ---
 
  Andrew Dunstan wrote:

  I wrote:
  
  Pavel Stehule wrote:

  Hello,
 
  I send two small patches. First does conversion from perl to 
  postgresql array in OUT parameters. Second patch allow hash form 
  output from procedures with one OUT argument.
 
  
  I will try to review these in the next 2 weeks unless someone beats me 
  to it.
 
 

  I have reviewed this lightly, as committed by Bruce, and have some 
  concerns. Unfortunately, the deathof my main workstation has cost me 
  much of the time I intended to use for a more thorough review, so there 
  may well be more issues than are outlined here.
 
  First, it is completely undocumented.
 
  Second, this comment is at best confusing:
 
/* if value is ref on array do to pg string array conversion */
 
 
  Third, it appears to assume that we will have names for all OUT params. 
  But names are optional, as I understand it. Arguably, we should be 
  treating the returns positionally, and thus return an arrayref when there 
  are OYT params, not a hashref, and ignore the names - after all, all perl 
  function args are nameless, in fact, even if you use a naming convention 
  to refer to them.
 
  Fourth, I don't understand the change: allow hash form output from 
  procedures with one OUT argument. That seems very non-orthogonal, and I 
  can't see any good reason for it.
 
  Lastly, if you look at the expected output as committed,it appears to have 
  been prepared without being actually examined, for example:
 
 
  CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
  $$ LANGUAGE plperl;
  SELECT '05' AS i,a FROM test05();
i  |a
   +-
05 | HASH(0x8558f9c)
   (1 row)
 
 
  what???
 
  And now that I look I see every buildfarm box broken on PLCheck. That's no 
  surprise at all.
 
 
  The conversation regarding these features appears only to have started on 
  July 28th, which was probably much too late given some of the issues. 
  Unless we can solve these issues very fast I would be inclined to say this 
  should be tabled for 8.3. I think this is a fairly good illustration of 
  the danger of springing a feature, largely undiscussed, on the community 
  just about freeze time.
 
  cheers
 
  andrew
  
 


-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] better support of out parameters in plperl

2007-02-08 Thread Andrew Dunstan


Has it been resubmitted with issues attended to? If it has, I missed it. 
If not, why should someone else waste time on something so broken that 
it produced a stringified perl  hashref on output? It should never have 
gone back in the queue IMNSHO.


cheers

andrew

Bruce Momjian wrote:

Would someone review this.  It is in the patches_hold queue:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---

Andrew Dunstan wrote:
  
I think it has to wait to 8.3. It's a complete mess that was submitted 
unheralded at the last moment. Pavel needs to get into the habit of 
submitting ideas first, not just patches. And there must be proper 
documentation and working regression tests.


cheers

andrew

Bruce Momjian wrote:


Uh, were are we in fixing/reviewing this?

---

Andrew Dunstan wrote:
  
  

I wrote:



Pavel Stehule wrote:
  
  

Hello,

I send two small patches. First does conversion from perl to 
postgresql array in OUT parameters. Second patch allow hash form 
output from procedures with one OUT argument.




I will try to review these in the next 2 weeks unless someone beats me 
to it.



  
  
I have reviewed this lightly, as committed by Bruce, and have some 
concerns. Unfortunately, the deathof my main workstation has cost me 
much of the time I intended to use for a more thorough review, so there 
may well be more issues than are outlined here.


First, it is completely undocumented.

Second, this comment is at best confusing:

  /* if value is ref on array do to pg string array conversion */


Third, it appears to assume that we will have names for all OUT params. But 
names are optional, as I understand it. Arguably, we should be treating the 
returns positionally, and thus return an arrayref when there are OYT params, 
not a hashref, and ignore the names - after all, all perl function args are 
nameless, in fact, even if you use a naming convention to refer to them.

Fourth, I don't understand the change: allow hash form output from procedures with 
one OUT argument. That seems very non-orthogonal, and I can't see any good reason 
for it.

Lastly, if you look at the expected output as committed,it appears to have been 
prepared without being actually examined, for example:


CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
   return {a='ahoj'};
 $$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
  i  |a
 +-

  05 | HASH(0x8558f9c)
 (1 row)


what???

And now that I look I see every buildfarm box broken on PLCheck. That's no 
surprise at all.


The conversation regarding these features appears only to have started on July 
28th, which was probably much too late given some of the issues. Unless we can 
solve these issues very fast I would be inclined to say this should be tabled 
for 8.3. I think this is a fairly good illustration of the danger of springing 
a feature, largely undiscussed, on the community just about freeze time.

cheers

andrew


  
  


  



---(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: [PATCHES] better support of out parameters in plperl

2007-02-08 Thread Bruce Momjian
Andrew Dunstan wrote:
 
 Has it been resubmitted with issues attended to? If it has, I missed it. 
 If not, why should someone else waste time on something so broken that 
 it produced a stringified perl  hashref on output? It should never have 
 gone back in the queue IMNSHO.

Fine, removed.  I don't understand Perl well enough to judge that.

---


 
 cheers
 
 andrew
 
 Bruce Momjian wrote:
  Would someone review this.  It is in the patches_hold queue:
 
  http://momjian.postgresql.org/cgi-bin/pgpatches_hold
 
  ---
 
  Andrew Dunstan wrote:

  I think it has to wait to 8.3. It's a complete mess that was submitted 
  unheralded at the last moment. Pavel needs to get into the habit of 
  submitting ideas first, not just patches. And there must be proper 
  documentation and working regression tests.
 
  cheers
 
  andrew
 
  Bruce Momjian wrote:
  
  Uh, were are we in fixing/reviewing this?
 
  ---
 
  Andrew Dunstan wrote:


  I wrote:
  
  
  Pavel Stehule wrote:


  Hello,
 
  I send two small patches. First does conversion from perl to 
  postgresql array in OUT parameters. Second patch allow hash form 
  output from procedures with one OUT argument.
 
  
  
  I will try to review these in the next 2 weeks unless someone beats me 
  to it.
 
 


  I have reviewed this lightly, as committed by Bruce, and have some 
  concerns. Unfortunately, the deathof my main workstation has cost me 
  much of the time I intended to use for a more thorough review, so there 
  may well be more issues than are outlined here.
 
  First, it is completely undocumented.
 
  Second, this comment is at best confusing:
 
/* if value is ref on array do to pg string array conversion */
 
 
  Third, it appears to assume that we will have names for all OUT params. 
  But names are optional, as I understand it. Arguably, we should be 
  treating the returns positionally, and thus return an arrayref when 
  there are OYT params, not a hashref, and ignore the names - after all, 
  all perl function args are nameless, in fact, even if you use a naming 
  convention to refer to them.
 
  Fourth, I don't understand the change: allow hash form output from 
  procedures with one OUT argument. That seems very non-orthogonal, and I 
  can't see any good reason for it.
 
  Lastly, if you look at the expected output as committed,it appears to 
  have been prepared without being actually examined, for example:
 
 
  CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
  return {a='ahoj'};
$$ LANGUAGE plperl;
  SELECT '05' AS i,a FROM test05();
i  |a
   +-
05 | HASH(0x8558f9c)
   (1 row)
 
 
  what???
 
  And now that I look I see every buildfarm box broken on PLCheck. That's 
  no surprise at all.
 
 
  The conversation regarding these features appears only to have started 
  on July 28th, which was probably much too late given some of the issues. 
  Unless we can solve these issues very fast I would be inclined to say 
  this should be tabled for 8.3. I think this is a fairly good 
  illustration of the danger of springing a feature, largely undiscussed, 
  on the community just about freeze time.
 
  cheers
 
  andrew
  
  


 

 
 
 ---(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

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(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: [PATCHES] better support of out parameters in plperl

2007-02-08 Thread Bruce Momjian

This patch has been rejected based on comments just made by Andrew
Dunstan.  If the author wants to revisit that, please reply and we can
discuss the issues.

---

Andrew Dunstan wrote:
 
 
 I wrote:
  Pavel Stehule wrote:
  Hello,
 
  I send two small patches. First does conversion from perl to 
  postgresql array in OUT parameters. Second patch allow hash form 
  output from procedures with one OUT argument.
 
 
  I will try to review these in the next 2 weeks unless someone beats me 
  to it.
 
 
 
 I have reviewed this lightly, as committed by Bruce, and have some 
 concerns. Unfortunately, the deathof my main workstation has cost me 
 much of the time I intended to use for a more thorough review, so there 
 may well be more issues than are outlined here.
 
 First, it is completely undocumented.
 
 Second, this comment is at best confusing:
 
   /* if value is ref on array do to pg string array conversion */
 
 
 Third, it appears to assume that we will have names for all OUT params. But 
 names are optional, as I understand it. Arguably, we should be treating the 
 returns positionally, and thus return an arrayref when there are OYT params, 
 not a hashref, and ignore the names - after all, all perl function args are 
 nameless, in fact, even if you use a naming convention to refer to them.
 
 Fourth, I don't understand the change: allow hash form output from 
 procedures with one OUT argument. That seems very non-orthogonal, and I 
 can't see any good reason for it.
 
 Lastly, if you look at the expected output as committed,it appears to have 
 been prepared without being actually examined, for example:
 
 
 CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
  return {a='ahoj'};
$$ LANGUAGE plperl;
 SELECT '05' AS i,a FROM test05();
   i  |a
  +-
   05 | HASH(0x8558f9c)
  (1 row)
 
 
 what???
 
 And now that I look I see every buildfarm box broken on PLCheck. That's no 
 surprise at all.
 
 
 The conversation regarding these features appears only to have started on 
 July 28th, which was probably much too late given some of the issues. Unless 
 we can solve these issues very fast I would be inclined to say this should be 
 tabled for 8.3. I think this is a fairly good illustration of the danger of 
 springing a feature, largely undiscussed, on the community just about freeze 
 time.
 
 cheers
 
 andrew

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] better support of out parameters in plperl

2006-09-02 Thread Bruce Momjian

Uh, were are we in fixing/reviewing this?

---

Andrew Dunstan wrote:
 
 
 I wrote:
  Pavel Stehule wrote:
  Hello,
 
  I send two small patches. First does conversion from perl to 
  postgresql array in OUT parameters. Second patch allow hash form 
  output from procedures with one OUT argument.
 
 
  I will try to review these in the next 2 weeks unless someone beats me 
  to it.
 
 
 
 I have reviewed this lightly, as committed by Bruce, and have some 
 concerns. Unfortunately, the deathof my main workstation has cost me 
 much of the time I intended to use for a more thorough review, so there 
 may well be more issues than are outlined here.
 
 First, it is completely undocumented.
 
 Second, this comment is at best confusing:
 
   /* if value is ref on array do to pg string array conversion */
 
 
 Third, it appears to assume that we will have names for all OUT params. But 
 names are optional, as I understand it. Arguably, we should be treating the 
 returns positionally, and thus return an arrayref when there are OYT params, 
 not a hashref, and ignore the names - after all, all perl function args are 
 nameless, in fact, even if you use a naming convention to refer to them.
 
 Fourth, I don't understand the change: allow hash form output from 
 procedures with one OUT argument. That seems very non-orthogonal, and I 
 can't see any good reason for it.
 
 Lastly, if you look at the expected output as committed,it appears to have 
 been prepared without being actually examined, for example:
 
 
 CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
  return {a='ahoj'};
$$ LANGUAGE plperl;
 SELECT '05' AS i,a FROM test05();
   i  |a
  +-
   05 | HASH(0x8558f9c)
  (1 row)
 
 
 what???
 
 And now that I look I see every buildfarm box broken on PLCheck. That's no 
 surprise at all.
 
 
 The conversation regarding these features appears only to have started on 
 July 28th, which was probably much too late given some of the issues. Unless 
 we can solve these issues very fast I would be inclined to say this should be 
 tabled for 8.3. I think this is a fairly good illustration of the danger of 
 springing a feature, largely undiscussed, on the community just about freeze 
 time.
 
 cheers
 
 andrew

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(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: [PATCHES] better support of out parameters in plperl

2006-09-02 Thread Andrew Dunstan


I think it has to wait to 8.3. It's a complete mess that was submitted 
unheralded at the last moment. Pavel needs to get into the habit of 
submitting ideas first, not just patches. And there must be proper 
documentation and working regression tests.


cheers

andrew

Bruce Momjian wrote:

Uh, were are we in fixing/reviewing this?

---

Andrew Dunstan wrote:
  

I wrote:


Pavel Stehule wrote:
  

Hello,

I send two small patches. First does conversion from perl to 
postgresql array in OUT parameters. Second patch allow hash form 
output from procedures with one OUT argument.



I will try to review these in the next 2 weeks unless someone beats me 
to it.



  
I have reviewed this lightly, as committed by Bruce, and have some 
concerns. Unfortunately, the deathof my main workstation has cost me 
much of the time I intended to use for a more thorough review, so there 
may well be more issues than are outlined here.


First, it is completely undocumented.

Second, this comment is at best confusing:

  /* if value is ref on array do to pg string array conversion */


Third, it appears to assume that we will have names for all OUT params. But 
names are optional, as I understand it. Arguably, we should be treating the 
returns positionally, and thus return an arrayref when there are OYT params, 
not a hashref, and ignore the names - after all, all perl function args are 
nameless, in fact, even if you use a naming convention to refer to them.

Fourth, I don't understand the change: allow hash form output from procedures with 
one OUT argument. That seems very non-orthogonal, and I can't see any good reason 
for it.

Lastly, if you look at the expected output as committed,it appears to have been 
prepared without being actually examined, for example:


CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
   return {a='ahoj'};
 $$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
  i  |a
 +-

  05 | HASH(0x8558f9c)
 (1 row)


what???

And now that I look I see every buildfarm box broken on PLCheck. That's no 
surprise at all.


The conversation regarding these features appears only to have started on July 
28th, which was probably much too late given some of the issues. Unless we can 
solve these issues very fast I would be inclined to say this should be tabled 
for 8.3. I think this is a fairly good illustration of the danger of springing 
a feature, largely undiscussed, on the community just about freeze time.

cheers

andrew



  


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [PATCHES] better support of out parameters in plperl

2006-09-02 Thread Bruce Momjian

OK.

This has been saved for the 8.3 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---

Andrew Dunstan wrote:
 
 I think it has to wait to 8.3. It's a complete mess that was submitted 
 unheralded at the last moment. Pavel needs to get into the habit of 
 submitting ideas first, not just patches. And there must be proper 
 documentation and working regression tests.
 
 cheers
 
 andrew
 
 Bruce Momjian wrote:
  Uh, were are we in fixing/reviewing this?
 
  ---
 
  Andrew Dunstan wrote:

  I wrote:
  
  Pavel Stehule wrote:

  Hello,
 
  I send two small patches. First does conversion from perl to 
  postgresql array in OUT parameters. Second patch allow hash form 
  output from procedures with one OUT argument.
 
  
  I will try to review these in the next 2 weeks unless someone beats me 
  to it.
 
 

  I have reviewed this lightly, as committed by Bruce, and have some 
  concerns. Unfortunately, the deathof my main workstation has cost me 
  much of the time I intended to use for a more thorough review, so there 
  may well be more issues than are outlined here.
 
  First, it is completely undocumented.
 
  Second, this comment is at best confusing:
 
/* if value is ref on array do to pg string array conversion */
 
 
  Third, it appears to assume that we will have names for all OUT params. 
  But names are optional, as I understand it. Arguably, we should be 
  treating the returns positionally, and thus return an arrayref when there 
  are OYT params, not a hashref, and ignore the names - after all, all perl 
  function args are nameless, in fact, even if you use a naming convention 
  to refer to them.
 
  Fourth, I don't understand the change: allow hash form output from 
  procedures with one OUT argument. That seems very non-orthogonal, and I 
  can't see any good reason for it.
 
  Lastly, if you look at the expected output as committed,it appears to have 
  been prepared without being actually examined, for example:
 
 
  CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
  $$ LANGUAGE plperl;
  SELECT '05' AS i,a FROM test05();
i  |a
   +-
05 | HASH(0x8558f9c)
   (1 row)
 
 
  what???
 
  And now that I look I see every buildfarm box broken on PLCheck. That's no 
  surprise at all.
 
 
  The conversation regarding these features appears only to have started on 
  July 28th, which was probably much too late given some of the issues. 
  Unless we can solve these issues very fast I would be inclined to say this 
  should be tabled for 8.3. I think this is a fairly good illustration of 
  the danger of springing a feature, largely undiscussed, on the community 
  just about freeze time.
 
  cheers
 
  andrew
  
 


-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [PATCHES] better support of out parameters in plperl

2006-09-02 Thread Bruce Momjian

Oh, let me add that this was first discussed on July 28:

http://archives.postgresql.org/pgsql-hackers/2006-07/msg01421.php

and a patch posted on July 30:

http://archives.postgresql.org/pgsql-hackers/2006-07/msg01559.php

---

Andrew Dunstan wrote:
 
 I think it has to wait to 8.3. It's a complete mess that was submitted 
 unheralded at the last moment. Pavel needs to get into the habit of 
 submitting ideas first, not just patches. And there must be proper 
 documentation and working regression tests.
 
 cheers
 
 andrew
 
 Bruce Momjian wrote:
  Uh, were are we in fixing/reviewing this?
 
  ---
 
  Andrew Dunstan wrote:

  I wrote:
  
  Pavel Stehule wrote:

  Hello,
 
  I send two small patches. First does conversion from perl to 
  postgresql array in OUT parameters. Second patch allow hash form 
  output from procedures with one OUT argument.
 
  
  I will try to review these in the next 2 weeks unless someone beats me 
  to it.
 
 

  I have reviewed this lightly, as committed by Bruce, and have some 
  concerns. Unfortunately, the deathof my main workstation has cost me 
  much of the time I intended to use for a more thorough review, so there 
  may well be more issues than are outlined here.
 
  First, it is completely undocumented.
 
  Second, this comment is at best confusing:
 
/* if value is ref on array do to pg string array conversion */
 
 
  Third, it appears to assume that we will have names for all OUT params. 
  But names are optional, as I understand it. Arguably, we should be 
  treating the returns positionally, and thus return an arrayref when there 
  are OYT params, not a hashref, and ignore the names - after all, all perl 
  function args are nameless, in fact, even if you use a naming convention 
  to refer to them.
 
  Fourth, I don't understand the change: allow hash form output from 
  procedures with one OUT argument. That seems very non-orthogonal, and I 
  can't see any good reason for it.
 
  Lastly, if you look at the expected output as committed,it appears to have 
  been prepared without being actually examined, for example:
 
 
  CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
  $$ LANGUAGE plperl;
  SELECT '05' AS i,a FROM test05();
i  |a
   +-
05 | HASH(0x8558f9c)
   (1 row)
 
 
  what???
 
  And now that I look I see every buildfarm box broken on PLCheck. That's no 
  surprise at all.
 
 
  The conversation regarding these features appears only to have started on 
  July 28th, which was probably much too late given some of the issues. 
  Unless we can solve these issues very fast I would be inclined to say this 
  should be tabled for 8.3. I think this is a fairly good illustration of 
  the danger of springing a feature, largely undiscussed, on the community 
  just about freeze time.
 
  cheers
 
  andrew
  
 


-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [PATCHES] better support of out parameters in plperl

2006-09-02 Thread Andrew Dunstan


Like I said, at the last moment.


Bruce Momjian wrote:

Oh, let me add that this was first discussed on July 28:

http://archives.postgresql.org/pgsql-hackers/2006-07/msg01421.php

and a patch posted on July 30:

http://archives.postgresql.org/pgsql-hackers/2006-07/msg01559.php

---

Andrew Dunstan wrote:
  
I think it has to wait to 8.3. It's a complete mess that was submitted 
unheralded at the last moment. Pavel needs to get into the habit of 
submitting ideas first, not just patches. And there must be proper 
documentation and working regression tests.


cheers

andrew

Bruce Momjian wrote:


Uh, were are we in fixing/reviewing this?

---

Andrew Dunstan wrote:
  
  

I wrote:



Pavel Stehule wrote:
  
  

Hello,

I send two small patches. First does conversion from perl to 
postgresql array in OUT parameters. Second patch allow hash form 
output from procedures with one OUT argument.




I will try to review these in the next 2 weeks unless someone beats me 
to it.



  
  
I have reviewed this lightly, as committed by Bruce, and have some 
concerns. Unfortunately, the deathof my main workstation has cost me 
much of the time I intended to use for a more thorough review, so there 
may well be more issues than are outlined here.


First, it is completely undocumented.

Second, this comment is at best confusing:

  /* if value is ref on array do to pg string array conversion */


Third, it appears to assume that we will have names for all OUT params. But 
names are optional, as I understand it. Arguably, we should be treating the 
returns positionally, and thus return an arrayref when there are OYT params, 
not a hashref, and ignore the names - after all, all perl function args are 
nameless, in fact, even if you use a naming convention to refer to them.

Fourth, I don't understand the change: allow hash form output from procedures with 
one OUT argument. That seems very non-orthogonal, and I can't see any good reason 
for it.

Lastly, if you look at the expected output as committed,it appears to have been 
prepared without being actually examined, for example:


CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
   return {a='ahoj'};
 $$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
  i  |a
 +-

  05 | HASH(0x8558f9c)
 (1 row)


what???

And now that I look I see every buildfarm box broken on PLCheck. That's no 
surprise at all.


The conversation regarding these features appears only to have started on July 
28th, which was probably much too late given some of the issues. Unless we can 
solve these issues very fast I would be inclined to say this should be tabled 
for 8.3. I think this is a fairly good illustration of the danger of springing 
a feature, largely undiscussed, on the community just about freeze time.

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: [PATCHES] better support of out parameters in plperl

2006-09-02 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 Uh, were are we in fixing/reviewing this?

It's dead for 8.2 --- Andrew's complaints are pretty serious at both
the conceptual and implementation levels, and there's been no sign of
discussion about how to fix them.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] better support of out parameters in plperl

2006-08-13 Thread Andrew Dunstan



I wrote:

Pavel Stehule wrote:

Hello,

I send two small patches. First does conversion from perl to 
postgresql array in OUT parameters. Second patch allow hash form 
output from procedures with one OUT argument.




I will try to review these in the next 2 weeks unless someone beats me 
to it.





I have reviewed this lightly, as committed by Bruce, and have some 
concerns. Unfortunately, the deathof my main workstation has cost me 
much of the time I intended to use for a more thorough review, so there 
may well be more issues than are outlined here.


First, it is completely undocumented.

Second, this comment is at best confusing:

 /* if value is ref on array do to pg string array conversion */


Third, it appears to assume that we will have names for all OUT params. But 
names are optional, as I understand it. Arguably, we should be treating the 
returns positionally, and thus return an arrayref when there are OYT params, 
not a hashref, and ignore the names - after all, all perl function args are 
nameless, in fact, even if you use a naming convention to refer to them.

Fourth, I don't understand the change: allow hash form output from procedures with 
one OUT argument. That seems very non-orthogonal, and I can't see any good reason 
for it.

Lastly, if you look at the expected output as committed,it appears to have been 
prepared without being actually examined, for example:


CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
   return {a='ahoj'};
 $$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
 i  |a
+-

 05 | HASH(0x8558f9c)
(1 row)


what???

And now that I look I see every buildfarm box broken on PLCheck. That's no 
surprise at all.


The conversation regarding these features appears only to have started on July 
28th, which was probably much too late given some of the issues. Unless we can 
solve these issues very fast I would be inclined to say this should be tabled 
for 8.3. I think this is a fairly good illustration of the danger of springing 
a feature, largely undiscussed, on the community just about freeze time.

cheers

andrew







---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] better support of out parameters in plperl

2006-08-13 Thread Bruce Momjian

Based on this analysis, and problems with differing regression results
on different platforms, this attached patch has been reverted.

---

Andrew Dunstan wrote:
 
 
 I wrote:
  Pavel Stehule wrote:
  Hello,
 
  I send two small patches. First does conversion from perl to 
  postgresql array in OUT parameters. Second patch allow hash form 
  output from procedures with one OUT argument.
 
 
  I will try to review these in the next 2 weeks unless someone beats me 
  to it.
 
 
 
 I have reviewed this lightly, as committed by Bruce, and have some 
 concerns. Unfortunately, the deathof my main workstation has cost me 
 much of the time I intended to use for a more thorough review, so there 
 may well be more issues than are outlined here.
 
 First, it is completely undocumented.
 
 Second, this comment is at best confusing:
 
   /* if value is ref on array do to pg string array conversion */
 
 
 Third, it appears to assume that we will have names for all OUT params. But 
 names are optional, as I understand it. Arguably, we should be treating the 
 returns positionally, and thus return an arrayref when there are OYT params, 
 not a hashref, and ignore the names - after all, all perl function args are 
 nameless, in fact, even if you use a naming convention to refer to them.
 
 Fourth, I don't understand the change: allow hash form output from 
 procedures with one OUT argument. That seems very non-orthogonal, and I 
 can't see any good reason for it.
 
 Lastly, if you look at the expected output as committed,it appears to have 
 been prepared without being actually examined, for example:
 
 
 CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
  return {a='ahoj'};
$$ LANGUAGE plperl;
 SELECT '05' AS i,a FROM test05();
   i  |a
  +-
   05 | HASH(0x8558f9c)
  (1 row)
 
 
 what???
 
 And now that I look I see every buildfarm box broken on PLCheck. That's no 
 surprise at all.
 
 
 The conversation regarding these features appears only to have started on 
 July 28th, which was probably much too late given some of the issues. Unless 
 we can solve these issues very fast I would be inclined to say this should be 
 tabled for 8.3. I think this is a fairly good illustration of the danger of 
 springing a feature, largely undiscussed, on the community just about freeze 
 time.
 
 cheers
 
 andrew
 
 
 
 
 

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: src/pl/plperl/plperl.c
===
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.115
retrieving revision 1.116
diff -c -r1.115 -r1.116
*** src/pl/plperl/plperl.c	12 Aug 2006 04:16:45 -	1.115
--- src/pl/plperl/plperl.c	13 Aug 2006 02:37:11 -	1.116
***
*** 1,7 
  /**
   * plperl.c - perl as a procedural language for PostgreSQL
   *
!  *	  $PostgreSQL: pgsql/src/pl/plperl/plperl.c,v 1.115 2006/08/12 04:16:45 momjian Exp $
   *
   **/
  
--- 1,7 
  /**
   * plperl.c - perl as a procedural language for PostgreSQL
   *
!  *	  $PostgreSQL: pgsql/src/pl/plperl/plperl.c,v 1.116 2006/08/13 02:37:11 momjian Exp $
   *
   **/
  
***
*** 52,57 
--- 52,58 
  	FmgrInfo	result_in_func; /* I/O function and arg for result type */
  	Oid			result_typioparam;
  	int			nargs;
+ 	int num_out_args;   /* number of out arguments */
  	FmgrInfo	arg_out_func[FUNC_MAX_ARGS];
  	bool		arg_is_rowtype[FUNC_MAX_ARGS];
  	SV		   *reference;
***
*** 115,120 
--- 116,124 
  static void plperl_init_shared_libs(pTHX);
  static HV  *plperl_spi_execute_fetch_result(SPITupleTable *, int, int);
  
+ static SV  *plperl_convert_to_pg_array(SV *src);
+ static SV *plperl_transform_result(plperl_proc_desc *prodesc, SV *result);
+ 
  /*
   * This routine is a crock, and so is everyplace that calls it.  The problem
   * is that the cached form of plperl functions/queries is allocated permanently
***
*** 404,410 
  	(errcode(ERRCODE_UNDEFINED_COLUMN),
  	 errmsg(Perl hash contains nonexistent column \%s\,
  			key)));
! 		if (SvOK(val)  SvTYPE(val) != SVt_NULL)
  			values[attn - 1] = SvPV(val, PL_na);
  	}
  	hv_iterinit(perlhash);
--- 408,419 
  	(errcode(ERRCODE_UNDEFINED_COLUMN),
  	 errmsg(Perl hash contains nonexistent column \%s\,
  			key)));
! 
! 		/* if value is ref on array do to pg string array conversion */
! 		if (SvTYPE(val) == SVt_RV 
! 			SvTYPE(SvRV(val)) == SVt_PVAV)
! 			values[attn - 1] = 

Re: [PATCHES] better support of out parameters in plperl

2006-08-11 Thread Bruce Momjian

Patch applied.  Thanks.

---


Pavel Stehule wrote:
 Hello,
 
 I send two small patches. First does conversion from perl to postgresql 
 array in OUT parameters. Second patch allow hash form output from procedures 
 with one OUT argument.
 
 Regards
 Pavel Stehule
 
 _
 Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. 
 http://www.msn.cz/

[ Attachment, skipping... ]

[ Attachment, skipping... ]

 
 ---(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

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] better support of out parameters in plperl

2006-08-01 Thread Andrew Dunstan

Pavel Stehule wrote:

Hello,

I send two small patches. First does conversion from perl to 
postgresql array in OUT parameters. Second patch allow hash form 
output from procedures with one OUT argument.




I will try to review these in the next 2 weeks unless someone beats me 
to it.


cheers

andrew

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings