Excerpts from Alex Hunsaker's message of sáb feb 12 04:53:14 -0300 2011:
- make plperl.o depend on plperl_helpers.h (should have been done in
the utf8 patch)
Incidentally, I think this bit was lost, no?
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt,
On Thu, Feb 17, 2011 at 16:18, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Alex Hunsaker's message of sáb feb 12 04:53:14 -0300 2011:
- make plperl.o depend on plperl_helpers.h (should have been done in
the utf8 patch)
Incidentally, I think this bit was lost, no?
It was,
Excerpts from Alvaro Herrera's message of mié feb 16 19:54:07 -0300 2011:
I cleaned up the patch a bit -- result is v11, attached. I'll give it
another look tomorrow and hopefully commit it.
Applied. Thanks.
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command
On Sat, Feb 12, 2011 at 02:17:12AM +0200, Alexey Klyukin wrote:
So, here is the v8. Instead of rewriting the encode_array_literal I've added
another function, encode_type_literal (could use a better name).
Given that encode_array_literal() encodes an _array_ as a literal,
I'd assume
Excerpts from Tim Bunce's message of mié feb 16 14:08:11 -0300 2011:
On Sat, Feb 12, 2011 at 02:17:12AM +0200, Alexey Klyukin wrote:
So, here is the v8. Instead of rewriting the encode_array_literal I've added
another function, encode_type_literal (could use a better name).
Given that
I cleaned up the patch a bit -- result is v11, attached. I'll give it
another look tomorrow and hopefully commit it.
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Feb 16, 2011 at 12:21, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Tim Bunce's message of mié feb 16 14:08:11 -0300 2011:
I'd suggest encode_typed_literal() as a better name.
FYI I'm looking at this patch (v10), and I'll incorporate Tim's suggestion.
Looks good to
On Feb 12, 2011, at 9:53 AM, Alex Hunsaker wrote:
On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin al...@commandprompt.com wrote:
Anyway in playing with this patch a bit more I found another bug
return [[]]; would segfault.
So find attached a v9 that:
- fixes above segfault
- made
On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
After I re-added the closing /para in plperl.sgml:235 these errors
disappeared, and the
resulting html looks fine too. v10 with just this single change is attached.
So is this ready for committer?
Best,
David
--
Sent via pgsql-hackers
On Feb 15, 2011, at 7:45 PM, David E. Wheeler wrote:
On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
After I re-added the closing /para in plperl.sgml:235 these errors
disappeared, and the
resulting html looks fine too. v10 with just this single change is attached.
So is this ready
On Feb 15, 2011, at 9:49 AM, Alexey Klyukin wrote:
After I re-added the closing /para in plperl.sgml:235 these errors
disappeared, and the
resulting html looks fine too. v10 with just this single change is attached.
So is this ready for committer?
Yes.
Awesom, thanks Alexey Alex!
On Feb 10, 2011, at 11:26 PM, Alexey Klyukin wrote:
On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote:
On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
Let me try implementing that as an XS interface to plperl_array_to_datum.
Are you intending this as a completion of the current patch
On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin al...@commandprompt.com wrote:
So, here is the v8. Instead of rewriting the encode_array_literal I've added
another function, encode_type_literal (could use a better name).
...
I can easily convert the encode_array_literal to just call this
On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote:
On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin al...@commandprompt.com wrote:
What was actually broken in encode_array_literal support of composite types
(it converted perl hashes to the literal composite-type constants, expanding
nested
On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote:
On Wed, Feb 9, 2011 at 08:24, Alexey Klyukinal...@commandprompt.com wrote:
What was actually broken in encode_array_literal support of composite types
(it converted perl hashes to the literal
On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote:
On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote:
On Wed, Feb 9, 2011 at 08:24, Alexey Klyukinal...@commandprompt.com
wrote:
What was actually broken in encode_array_literal support of
On Feb 9, 2011, at 3:44 AM, Alex Hunsaker wrote:
So the merge while not exactly trivial was fairly simple. However it
would be great if you could give it another look over.
Find attached v7 changes include:
- rebased against HEAD
- fix potential use of uninitialized dims[cur_depth]
-
On Tue, Feb 08, 2011 at 09:40:38AM -0500, Andrew Dunstan wrote:
On 02/03/2011 01:20 PM, Andrew Dunstan wrote:
Well, the question seems to be whether or not it's a reasonable
price to pay. On the whole I'm inclined to think it is, especially
when it can be avoided by updating your code, which
On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin al...@commandprompt.com wrote:
What was actually broken in encode_array_literal support of composite types
(it converted perl hashes to the literal composite-type constants, expanding
nested arrays along the way) ? I think it would be a useful
On 02/03/2011 01:20 PM, Andrew Dunstan wrote:
- Every existing plperl function that takes arrays is going to get
slower due to the overhead of parsing the string and allocating the
array and all its elements.
Well, per my understanding of Alex changes, the string parsing is
not invoked
On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker bada...@gmail.com wrote:
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin al...@commandprompt.com
wrote:
I've looked at the patch and added a test for arrays exceeding or equal
maximum dimensions to
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin al...@commandprompt.com wrote:
On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
So here is a v6
Comments?
Thanks, looks great to me. It passes all the tests on my OS X system. I wonder
what's the purpose of the amagic_call in
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin al...@commandprompt.com wrote:
Thanks, looks great to me. It passes all the tests on my OS X system. I
wonder
what's the purpose of the amagic_call in get_perl_array_ref, instead
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin al...@commandprompt.com wrote:
On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
So here is a v6
Comments?
Thanks, looks great to me. It passes all the tests on my OS X
On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker bada...@gmail.com wrote:
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin al...@commandprompt.com wrote:
I've looked at the patch and added a test for arrays exceeding or equal
maximum dimensions to check, whether the recursive function won't bring
On 02/03/2011 08:29 PM, Alex Hunsaker wrote:
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukinal...@commandprompt.com wrote:
I've looked at the patch and added a test for arrays exceeding or equal maximum
dimensions to check, whether the recursive function won't bring surprises
there. I've
On Fri, Feb 4, 2011 at 10:29, Andrew Dunstan and...@dunslane.net wrote:
Anyone object to fixing the above as part of this patch? That is
making plperl_(build_tuple_result, modify_tuple, return_next,
hash_from_tuple) handle array and hash (composite/row) types
consistently? And _that_ would be
Hi,
On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
I'm sorry I'm late to this party. I haven't been keeping up with
pgsql-hackers.
Better late than never :)
I'd kind'a hoped that this functionality could be tied into extending
PL/Perl to handle named arguments. That way the perl variables
On Feb 3, 2011, at 4:23 AM, Alexey Klyukin wrote:
- Making the conversion lazy would be a big help.
Converting it to string is already lazy, and, per the argumens above, I don't
see a real benefit of lazy conversion to the perl reference (as comparing to
the hurdles of implementing that).
On Thu, Feb 03, 2011 at 02:23:32PM +0200, Alexey Klyukin wrote:
Hi,
On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
I'm sorry I'm late to this party. I haven't been keeping up with
pgsql-hackers.
Better late than never :)
I'd kind'a hoped that this functionality could be tied into
On 02/03/2011 01:01 PM, Tim Bunce wrote:
Imagine that PL/Perl could handle named arguments:
CREATE FUNCTION join_list( separator text, list array ) AS $$
return join( $separator, @$list );
$$ LANGUAGE plperl;
The $list variable, magically created by PL/Perl, could be the
On tor, 2011-02-03 at 18:01 +, Tim Bunce wrote:
Imagine that PL/Perl could handle named arguments:
CREATE FUNCTION join_list( separator text, list array ) AS $$
return join( $separator, @$list );
$$ LANGUAGE plperl;
The $list variable, magically created by PL/Perl,
On Thu, Feb 3, 2011 at 05:23, Alexey Klyukin al...@commandprompt.com wrote:
Hi,
On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
[...]
Some observations on the current code (based on a quick skim):
- I'd like to see the conversion function exposed as a builtin
$ref =
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin al...@commandprompt.com wrote:
I've looked at the patch and added a test for arrays exceeding or equal
maximum dimensions to check, whether the recursive function won't bring
surprises there. I've also added check_stack_depth calls to both
I'm sorry I'm late to this party. I haven't been keeping up with pgsql-hackers.
I'd kind'a hoped that this functionality could be tied into extending
PL/Perl to handle named arguments. That way the perl variables
corresponding to the named arguments could be given references without
breaking any
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin al...@commandprompt.com wrote:
I've looked at the patch and added a test for arrays exceeding or equal
maximum dimensions to check, whether the recursive function won't bring
surprises there. I've also added check_stack_depth calls to both
On Jan 29, 2011, at 12:27 AM, Alex Hunsaker wrote:
On Thu, Jan 27, 2011 at 03:38, Alexey Klyukin al...@commandprompt.com wrote:
Hi,
On Jan 27, 2011, at 9:31 AM, Alex Hunsaker wrote:
Find attached v3 of the patch. changes include:
- fix deep recursion due to accidental reversal of check
On Thu, Jan 27, 2011 at 03:38, Alexey Klyukin al...@commandprompt.com wrote:
Hi,
On Jan 27, 2011, at 9:31 AM, Alex Hunsaker wrote:
Find attached v3 of the patch. changes include:
- fix deep recursion due to accidental reversal of check in
encode_array_literal
- add proper support for
Hi,
On Jan 27, 2011, at 9:31 AM, Alex Hunsaker wrote:
Find attached v3 of the patch. changes include:
- fix deep recursion due to accidental reversal of check in
encode_array_literal
- add proper support for stringifying composite/row types. I did not
find a good way to quote these from
On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin al...@commandprompt.com wrote:
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string
Hi,
On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin al...@commandprompt.com
wrote:
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
On Jan 12, 2011, at 5:14 AM,
On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin al...@commandprompt.com wrote:
Hi,
On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin al...@commandprompt.com
wrote:
On Jan 12,
On Jan 26, 2011, at 10:08 PM, Alex Hunsaker wrote:
On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin al...@commandprompt.com wrote:
Hi,
On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Jan 12, 2011 at 13:04,
On Wed, Jan 26, 2011 at 13:35, Alexey Klyukin al...@commandprompt.com wrote:
On Jan 26, 2011, at 10:08 PM, Alex Hunsaker wrote:
(it's obviously reversed comparing with the original one), but it still
segfaults after I fixed that.
Ahh yep, the reason reversing the check did not fix it is
Find attached v3 of the patch. changes include:
- fix deep recursion due to accidental reversal of check in encode_array_literal
- add proper support for stringifying composite/row types. I did not
find a good way to quote these from the perl on the fly, so instead we
compute it the same way we
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin al...@commandprompt.com wrote:
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string representation and a reference to a single
SV * value?
Dunno, I'm not a guts
On Thu, Jan 13, 2011 at 12:06:33AM -0700, Alex Hunsaker wrote:
I had supposed that it would be possible to do the string conversion
lazily, ie, only if the string value was actually demanded.
Yep, In-fact if we wanted we could even die (or throw an exception in
other language speak :) )
On Thu, Jan 13, 2011 at 01:06, Martijn van Oosterhout klep...@svana.org wrote:
On Thu, Jan 13, 2011 at 12:06:33AM -0700, Alex Hunsaker wrote:
I had supposed that it would be possible to do the string conversion
lazily, ie, only if the string value was actually demanded.
Yep, In-fact if we
On Thu, Jan 13, 2011 at 2:06 AM, Martijn van Oosterhout
klep...@svana.org wrote:
I played with this a little and it is fairly easy to make a variable
such that $a is the string representation and $a[0] the first value of
the array. The problem is that you can't pass such a variable into a
On Jan 13, 2011, at 4:15 PM, Stephen J. Butler wrote:
Suppose one of these compatibility objects is passed into legacy code
as $_[0]. The problem is that 'ref $_[0]' will return 'Pg::ArrayArg'
instead of what it used to, '' (empty string). Other than that, I
think it performs as people would
On Jan 12, 2011, at 1:07 AM, David E. Wheeler wrote:
On Jan 11, 2011, at 2:25 PM, Alexey Klyukin wrote:
Hello,
Here's the patch that improves handling of arrays as pl/perl function input
arguments, converting postgres arrays of arbitrary dimensions into perl array
references.
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/11/2011 07:17 PM, David E. Wheeler wrote:
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string representation and a reference to a single SV
* value?
Dunno, I'm not a guts guy.
I haven't considered that (lack of extensive perlgus-foo) although I think
that's an interesting idea. One drawback would be
On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin al...@commandprompt.com wrote:
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
By the same token, I'm not convinced it's a good idea for this
behavior to be off by default. Surely many people will altogether
fail to notice that it's an option?
On Jan 12, 2011, at 11:22 AM, Alex Hunsaker wrote:
Personally, I think the point of a compatibility GUC is that at some
point in the distant future we can get rid of it. If we default to
the old behavior thats going to be harder to do. +1 for defaulting to
the new behavior.
+1
[ Id
On Wed, Jan 12, 2011 at 12:22:55PM -0700, Alex Hunsaker wrote:
On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin al...@commandprompt.com wrote:
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
By the same token, I'm not convinced it's a good idea for this
behavior to be off by default. Surely
Excerpts from Alex Hunsaker's message of mié ene 12 16:22:55 -0300 2011:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major things in minor releases, for example the removal of
Safe.pm) ]
On Jan 12, 2011, at 11:36 AM, Alvaro Herrera wrote:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major things in minor releases, for example the removal of
Safe.pm) ]
I think the main
Excerpts from David E. Wheeler's message of mié ene 12 16:39:56 -0300 2011:
On Jan 12, 2011, at 11:36 AM, Alvaro Herrera wrote:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major
On Jan 12, 2011, at 11:51 AM, Alvaro Herrera wrote:
I suspect it'd be quiet, unfortunately, since there are a bazillion ad hoc
implementations of a Perl SQL array parser, and many of them, I suspect,
don't complain if the string doesn't look like an SQL array. They would just
parse a
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string representation and a reference to a single SV
* value?
Dunno, I'm not a guts guy.
Well, neither me (I haven't used much of the guts api there).
I
On Jan 12, 2011, at 9:36 PM, Alvaro Herrera wrote:
Excerpts from Alex Hunsaker's message of mié ene 12 16:22:55 -0300 2011:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major things in
Excerpts from David E. Wheeler's message of mié ene 12 16:55:17 -0300 2011:
On Jan 12, 2011, at 11:51 AM, Alvaro Herrera wrote:
I suspect it'd be quiet, unfortunately, since there are a bazillion ad hoc
implementations of a Perl SQL array parser, and many of them, I suspect,
don't
Alexey Klyukin al...@commandprompt.com writes:
Since almost everyone votes for making the new behavior a default option I'm
inclined to do that change, although I'm against throwing out the
compatibility option. There are many other reasons except for PL/Perl for
people to upgrade to 9.1,
On 01/12/2011 04:22 PM, Tom Lane wrote:
Alexey Klyukinal...@commandprompt.com writes:
Since almost everyone votes for making the new behavior a default option I'm
inclined to do that change, although I'm against throwing out the
compatibility option. There are many other reasons except for
On Wed, Jan 12, 2011 at 4:45 PM, Andrew Dunstan and...@dunslane.net wrote:
I thought the idea of overloading the string representation to look like
the old style was a cute solution. If we don't have anyone at hand who
knows how to do that, let's find someone who does. Not break our users'
On Jan 12, 2011, at 3:29 PM, Robert Haas wrote:
What I was casting a bit of doubt on upthread was whether or not this would
work without possibly breaking some code, in possibly silent or obscure
ways. If I'm wrong about that, then by all means let's use some perl Magic
(that's a technical
David E. Wheeler da...@kineticode.com writes:
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing that. Say
you have some code that does a ref test on the argument, for example. The
behavior would now be changed.
I think that'd
David E. Wheeler da...@kineticode.com writes:
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string representation and a reference to a single SV
* value?
Dunno, I'm not a guts guy.
I haven't considered that (lack of extensive perlgus-foo) although I
think
On Wed, Jan 12, 2011 at 22:12, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string representation and a reference to a single
SV * value?
Dunno, I'm not a guts guy.
I haven't
On Wed, Jan 12, 2011 at 14:45, Andrew Dunstan and...@dunslane.net wrote:
What I was casting a bit of doubt on upthread was whether or not this would
work without possibly breaking some code, in possibly silent or obscure
ways.
I can't see how it would break, unless we did it wrong...
If I'm
On Jan 11, 2011, at 2:25 PM, Alexey Klyukin wrote:
Hello,
Here's the patch that improves handling of arrays as pl/perl function input
arguments, converting postgres arrays of arbitrary dimensions into perl array
references.
Awesome! I've wanted this for *years*.
It includes regression
On 01/11/2011 06:07 PM, David E. Wheeler wrote:
To maintain
compatibility with existing pl/perl code a new variable,
plperl.convert_array_arguments (better name?), is introduced. Its default
value is false, when set to true it triggers the new behavior, i.e.
Have you considered instead
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing that. Say you
have some code that does a ref test on the argument, for example. The
behavior would now be changed.
I think that'd be pretty rare.
David
--
Sent via
On 01/11/2011 07:17 PM, David E. Wheeler wrote:
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing that. Say you
have some code that does a ref test on the argument, for example. The behavior
would now be changed.
I think
On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/11/2011 07:17 PM, David E. Wheeler wrote:
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing that. Say
you have some code that does a ref test on
On 01/11/2011 09:06 PM, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstanand...@dunslane.net wrote:
On 01/11/2011 07:17 PM, David E. Wheeler wrote:
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing that. Say
77 matches
Mail list logo
