Re: arrays as pl/perl input arguments [PATCH]

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexey Klyukin <alexk(at)commandprompt(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: arrays as pl/perl input arguments [PATCH]
Date: 2011-01-13 07:28:54
Message-ID: AANLkTim-ANJTH-4j1KrEC=3O_AVqjPCAZZitgmWY8buq@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 12, 2011 at 14:45, Andrew Dunstan <andrew(at)dunslane(dot)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 wrong about that, then by all means let's use some perl Magic
> (that's a technical term) to achieve this. IIRC Alex recently posted some
> code that might be instructive about this.

There might be a more gutsy way to do this so that 'ref' gives you
back what you expected (would that be 'ARRAY' or 'SCALAR' ?), but
there is a simple pure perl solution using overload:
package PLPerl::ArgArray;
use overload '""' => \&to_str;

sub new
{
# note we bless an arrayref here instead of the usual hashref so
# you can use this 'object' as a normal array
return bless([(at)_], ... );
}

sub to_str
{
my $self = shift;
# yeah this is not right not correct :P
# we could also die here with something like "You are trying to use
an Array as a string" or whatever
return join(',', map { '{'. $_ .'}' } @{$self});
}
---------

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2011-01-13 07:40:01 Re: Change pg_last_xlog_receive_location not to move backwards
Previous Message Fujii Masao 2011-01-13 07:24:31 Change pg_last_xlog_receive_location not to move backwards