It seems that function get arrays as strings in plperl.
This is a little workaround who want pass arrays to plperl functions
my( $strarr )= @_;
$strarr =~ s/{/[/g;
$strarr =~ s/}/]/g;
my $arr= eval $strarr;
NOTICE:
you must create you function as plperlu
and add language:
create language plperlu;
On Sun, Mar 30, 2008 at 04:23:07PM +0300, [EMAIL PROTECTED] wrote:
> It seems that function get arrays as strings in plperl.
> This is a little workaround who want pass arrays to plperl functions
>
> my( $strarr )= @_;
> $strarr =~ s/{/[/g;
> $strarr =~ s/}/]/g;
> my $arr= eval $strarr;
>
> NOTIC
Yes, It is dangerous. But there is no other way to get arrays for plperl
The doc says that all passed to plperl function are strings ((
Another strange is that that '{1,2,3,4}' looks as hash in perl
It will be more conviniet if arrays passed as '[1,2,3,4]' strings if PG can
not pass them as arra
The following bug has been logged online:
Bug reference: 4069
Logged by: Eduard Fernandez-Diaz
Email address: [EMAIL PROTECTED]
PostgreSQL version: 1.8.0
Operating system: Ubuntu - Linux
Description:Wrong tip
Details:
Wrong tip at the beginning of the administrator:
On Sun, Mar 30, 2008 at 1:52 PM, Eduard Fernandez-Diaz
<[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4069
> Logged by: Eduard Fernandez-Diaz
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 1.8.0
> Operating system: Ubuntu -
PROBLEM:
How to FULL JOIN groups=1 from table 'a' with groups=2 from table 'b'
and exclude original NULL groups not thouse which FULL JOIN produce?
DESCRIPTION:
I have a schema which is attached at file '123':
while FULL JOIN ing I get:
postgres=# SELECT * FROM a FULL JOIN b ON a.num1 = b.num1;
"Dave Page" <[EMAIL PROTECTED]> writes:
>> Wrong tip at the beginning of the administrator: "The answer to the
>> question of Life, the Universe and Everything is 42." The answer is "God
>> created them."
>
> I'm not so sure - can you define exactly what 'the question' is? That
> will probably hel
<[EMAIL PROTECTED]> writes:
> PROBLEM:
> How to FULL JOIN groups=1 from table 'a' with groups=2 from table 'b'
> and exclude original NULL groups not thouse which FULL JOIN produce?
...
SELECT *
FROM (select * from a where a.groups = 1) AS a
FULL OUTER JOIN (select * from b where b.groups = 2)
On Sun, 30 Mar 2008 [EMAIL PROTECTED] wrote:
> PROBLEM:
> How to FULL JOIN groups=1 from table 'a' with groups=2 from table 'b'
> and exclude original NULL groups not thouse which FULL JOIN produce?
As far as I can tell, all the results you got were exactly what the SQL
spec requires for the que
Hello all,
as already known, 8.3 now enforces a match between DB encoding and
server locale [1]. I agree that this is a Good Thing™, but it causes
automatic upgrades from previous versions to 8.3 to fail with
something like
pg_restore: [archiver (db)] could not execute query: ERROR: encoding LAT
Hi again,
Martin Pitt [2008-03-30 20:40 +0200]:
> My current pg_upgradecluster uses pg_dumpall to copy the schema, and a
> per-db pg_dump to copy the DB table contents. Will calling pg_dump
> with --encoding= always DTRT and is
> it meant to solve this problem?
One problem with this is that whil
Martin Pitt <[EMAIL PROTECTED]> writes:
> One problem with this is that while pg_dump -E UTF8 works (with SQL
> output), -E does not seem to have any effect when using -Fc.
Huh? Please provide a test case.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bug
Tom Lane [2008-03-30 16:43 -0400]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > One problem with this is that while pg_dump -E UTF8 works (with SQL
> > output), -E does not seem to have any effect when using -Fc.
>
> Huh? Please provide a test case.
Ah, I got it. This fails:
pg_dump -Fc -E U
Martin Pitt <[EMAIL PROTECTED]> writes:
> Tom Lane [2008-03-30 16:43 -0400]:
>> Huh? Please provide a test case.
> Ah, I got it. This fails:
> pg_dump -Fc -E UTF8 -p 5432 latin1test | pg_restore -p 5433 -d template1 -C
> (5432 is 8.1, 5433 is 8.3, both with locale ru_RU.UTF-8;
> createdb -E
Hi Tom,
Tom Lane [2008-03-30 17:15 -0400]:
> > pg_dump -Fc -E UTF8 -p 5432 latin1test | pg_restore -p 5433 -d template1
> > -C
>
> Yeah. This will try to create the new latin1test with all the same
> properties it had before, including encoding
I see, so it's intended to behave like this. m
Martin Pitt <[EMAIL PROTECTED]> writes:
> BTW, many people seem to run the server under C and use different
> encodings in their DBs (latin, UTF8). Shouldn't that cause similar
> problems with collation, data type checking (ischar(), etc.)? What do
> you recommend should the upgrade script do if it
16 matches
Mail list logo
