On 09/29/2017 01:10 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/28/2017 05:44 PM, Tom Lane wrote:
>>> Assuming that that's going to happen for v11, I'm inclined to leave the
>>> optimization problem until the dust settles around CaseTestExpr.
>>> Does anyone feel that this can't be com
Andrew Dunstan writes:
> On 09/28/2017 05:44 PM, Tom Lane wrote:
>> Assuming that that's going to happen for v11, I'm inclined to leave the
>> optimization problem until the dust settles around CaseTestExpr.
>> Does anyone feel that this can't be committed before that's addressed?
> I'm Ok with i
On 09/28/2017 05:44 PM, Tom Lane wrote:
>
> I get these query timings in a non-cassert build:
>
> HEADPatch
>
> Q15453.235 ms 5440.876 ms
> Q29340.670 ms 10191.194 ms
> Q319078.457 ms18967.279 ms
> Q448196.338 ms58547.531 ms
>
>
[ analysis elided]
Andrew Dunstan writes:
> On 09/28/2017 01:11 PM, Tom Lane wrote:
>>> I wonder if we need to do any benchmarking to assure ourselves that the
>>> changes to ArrayCoerceExpr don't have a significant performance impact?
>> That would likely be a good idea, though I'm not very sure what or
>> how to
On 09/28/2017 01:11 PM, Tom Lane wrote:
>
>> I wonder if we need to do any benchmarking to assure ourselves that the
>> changes to ArrayCoerceExpr don't have a significant performance impact?
> That would likely be a good idea, though I'm not very sure what or
> how to benchmark.
>
>
Andrew Dunstan writes:
> On 08/11/2017 01:17 PM, Tom Lane wrote:
>> Attached is a patch series that allows us to create arrays of domain
>> types.
> I've reviewed and tested the updated versions of these patches. The
> patches apply but there's an apparent typo in arrayfuncs.c -
> DatumGetAnyArra
On 08/11/2017 01:17 PM, Tom Lane wrote:
> I wrote:
>> Probably a better answer is to start supporting arrays over domain
>> types. That was left unimplemented in the original domains patch,
>> but AFAICS not for any better reason than lack of round tuits.
> Attached is a patch series that allows
I wrote:
> Here's a rebased-up-to-HEAD version of this patch set. The only
> actual change is removal of a no-longer-needed hunk in pl_exec.c.
I see the patch tester is complaining that this broke, due to commit
4bd199465. The fix is trivial (s/GETARG_ANY_ARRAY/GETARG_ANY_ARRAY_P/)
but for conve
I wrote:
> Attached is a patch series that allows us to create arrays of domain
> types.
Here's a rebased-up-to-HEAD version of this patch set. The only
actual change is removal of a no-longer-needed hunk in pl_exec.c.
regards, tom lane
diff --git a/src/backend/optimizer
I wrote:
> Probably a better answer is to start supporting arrays over domain
> types. That was left unimplemented in the original domains patch,
> but AFAICS not for any better reason than lack of round tuits.
Attached is a patch series that allows us to create arrays of domain
types. I haven't
On 07/11/2017 12:44 PM, Tom Lane wrote:
>
> Can anyone think of a reason not to pursue that?
>
>
I'm all for it.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pg
On Tue, Jul 11, 2017 at 12:44:33PM -0400, Tom Lane wrote:
> Over in
> https://www.postgresql.org/message-id/877ezgyn60@metapensiero.it
> there's a gripe about array_agg() not working for a domain type.
> It fails because we don't create an array type over a domain type,
> so the parser can't id
Over in
https://www.postgresql.org/message-id/877ezgyn60@metapensiero.it
there's a gripe about array_agg() not working for a domain type.
It fails because we don't create an array type over a domain type,
so the parser can't identify a suitable output type for the polymorphic
aggregate.
We cou
On Jul 12, 2011, at 12:19 PM, Alex Hunsaker wrote:
> All Arrays in 9.0 and lower are strings, regardless of if they are
> comprised of composite types. Its not so much a bug as a limitation.
> Alexey Klyukin fixed this for 9.1 :-)
Oh?
dump
--
On Tue, Jul 12, 2011 at 12:45, David E. Wheeler wrote:
> Hackers,
> That is, if a record is passed to a PL/Perl function, it's correctly
> converted into a hash. If, however, an array of records are passed, the
> record are stringified, rather than turned into hashes. This seems
> inconsistent
Hackers,
Given this script:
BEGIN;
CREATE TYPE foo AS ( this int, that int );
CREATE OR REPLACE FUNCTION dump(foo[]) returns text language plperlu AS $$
use Data::Dumper; Dumper shift;
$$;
CREATE OR REPLACE FUNCTION dump(foo) returns text language plperlu AS $$
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
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Rep
On Thu, Feb 17, 2011 at 16:18, Alvaro Herrera
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, yes.
--
Sent via
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
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication,
On Wed, Feb 16, 2011 at 12:21, Alvaro Herrera
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 me.
--
Sent via pgsql
On 02/16/2011 05:54 PM, Alvaro Herrera wrote:
I cleaned up the patch a bit -- result is v11, attached. I'll give it
another look tomorrow and hopefully commit it.
Thanks for picking this up.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
I cleaned up the patch a bit -- result is v11, attached. I'll give it
another look tomorrow and hopefully commit it.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
pg_to_perl_arrays_v11.patch.gz
Description
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
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 encode_
On Feb 15, 2011, at 9:49 AM, Alexey Klyukin wrote:
>>> After I re-added the closing 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 &
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 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 re
On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
> After I re-added the closing 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 mail
On Feb 12, 2011, at 9:53 AM, Alex Hunsaker wrote:
> On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin 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 plperl_sv_to_literal
On Fri, Feb 11, 2011 at 17:17, 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).
> ...
> I can easily convert the encode_array_literal to just call this function, but
> not encode_
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
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 Klyukin
>>> wrote:
What was actually broken in encode_array_literal support of composite
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 Klyukin wrote:
What was actually broken in encode_array_literal support of composite types
(it converted perl hashes to the literal composite-type constants, e
On Feb 9, 2011, at 9:28 PM, Alex Hunsaker wrote:
> On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin 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
On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin 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 extension of the
> existi
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 cod
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 8, 2011 at 10:33, Alex Hunsaker wrote:
> On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin 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
>>
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker wrote:
> On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin 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 of
>> calling newRV_noinc on the t
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin 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 get_perl_array_ref, instea
On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
> On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker wrote:
>> On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin
>> wrote:
>>> I've looked at the patch and added a test for arrays exceeding or equal
>>> maximum dimensions to check, whether the recursive f
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
unl
On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker wrote:
> On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin 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 che
On Fri, Feb 4, 2011 at 10:29, Andrew Dunstan 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 to recurse a
On 02/03/2011 08:29 PM, Alex Hunsaker wrote:
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin 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_dept
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin 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 split_array
> and plperl_ha
On Thu, Feb 3, 2011 at 05:23, Alexey Klyukin 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 = decode_array_literal("{...}");
>
>
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/Per
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 a
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
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 tha
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 varia
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 c
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin 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 split_array
> and plperl_h
On Jan 29, 2011, at 12:27 AM, Alex Hunsaker wrote:
> On Thu, Jan 27, 2011 at 03:38, Alexey Klyukin 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
>>>
On Thu, Jan 27, 2011 at 03:38, Alexey Klyukin 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 stringifying co
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 f
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 u
On Wed, Jan 26, 2011 at 13:35, Alexey Klyukin 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 order of
operations
On Jan 26, 2011, at 10:08 PM, Alex Hunsaker wrote:
> On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin wrote:
>> Hi,
>>
>> On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
>>
>>> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
wrote:
On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin wrote:
> Hi,
>
> On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
>
>> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>>> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
>>> wrote:
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>
Hi,
On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
>> wrote:
>>>
>>> On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>>>
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin 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
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin 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 guy.
>
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 wou
On Thu, Jan 13, 2011 at 2:06 AM, Martijn van Oosterhout
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
> subroutine.
I pla
On Thu, Jan 13, 2011 at 01:06, Martijn van Oosterhout 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 wanted w
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 Wed, Jan 12, 2011 at 14:45, Andrew Dunstan 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 wrong about th
On Wed, Jan 12, 2011 at 22:12, Tom Lane wrote:
> "David E. Wheeler" 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
"David E. Wheeler" 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 that's an inter
"David E. Wheeler" 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 be pretty
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 techn
On Wed, Jan 12, 2011 at 4:45 PM, Andrew Dunstan 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'
>> code because
On 01/12/2011 04:22 PM, Tom Lane wrote:
Alexey Klyukin 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 upg
Alexey Klyukin 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, let's not force them to
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,
> >> d
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 th
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).
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
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
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
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 Wed, Jan 12, 2011 at 12:22:55PM -0700, Alex Hunsaker wrote:
> On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin 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
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 a
On Wed, Jan 12, 2011 at 06:34, Alexey Klyukin 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? If we're going to
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
On Jan 12, 2011, at 4:06 AM, Robert Haas wrote:
> On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan 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
>
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 01/11/2011 09:06 PM, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan 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
On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan 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 the argumen
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 that
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 pgsql-
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 passi
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 regressi
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. It includes regression tests and a documentation changes, and it
builds and runs successfully on my mac os x and linux boxes.
Hi,
I'd like to improve the way PL/Perl handles arrays as function input
parameters. In PL/Perl arrays are passed as plain text strings, and getting a
value of an array element requires additional perl code to parse that string.
I'd like to make this easier by converting each postgresq array pa
On 5/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
BTW, in the array patch as just committed, I was able to get rid of the
I am testing this feature, no problem so far. It's fast, and works
exactly as advertised! Great work! (aiui, no domain arrays for 8.3?)
merlin
---
Awhile back I wrote:
> I did some tests just now to determine the total number of catalog
> entries associated with a simple table definition. Assuming it has
> N user columns of built-in types (hence not requiring pg_depend entries
> for the datatypes), I count
> 1 pg_class entry for the table i
On Sun, May 06, 2007 at 01:33:47PM -0400, Andrew Dunstan wrote:
> However, there are still some oddities. For example, a change to or
> removal of the base type affects the array type, but the array type
> can be directly operated on (e.g. alter type _aa set schema foo ).
> I'm inclined to say we
I wrote:
OK, summarising what looks to me like a consensus position, ISTM the
plan could be:
. fix makeArrayTypeName() or similar to make it try harder to generate
a unique non-clashing name
. remove the existing "62 instead of 63" name length restrictions
. autogenerate array types for a
1 - 100 of 180 matches
Mail list logo
