On Mon, Jul 15, 2013 at 5:56 AM, Ming Lai wrote:
> I know how elog works. elog only show the status, but it does not allow me
> to execute another query when the current query fails because one of the
> invalid column was specified.
Hrm? Im not sure what you mean. If you elog(ERROR) outside of
On Wed, Jul 10, 2013 at 2:36 PM, Alex Lai wrote:
> Dear all,
>
> I have a situation. I am unable to pass control back to the function once
> it hit the "undefined_column" error code.
> I am not sure there's a way to return '123' instead exit from the function.
>
> Here is my code
>
> CREATE OR RE
On Wed, May 16, 2012 at 11:53 AM, Tom Lane wrote:
> Alex Hunsaker writes:
>> That being said it seems we failed to take any magic (aka string
>> overloads) that a blessed reference might have. Ill see about
>> submitting a patch for 9.3 (9.2 just entered beta). Anyone have
On Wed, May 16, 2012 at 10:47 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6645
> Logged by: Evna Carroll
> Email address: m...@evancarroll.com
> PostgreSQL version: 9.1.2
> Operating system: Linux
> Description:
>
> This is a cross post f
On Sat, Apr 28, 2012 at 17:20, Ryan Kelly wrote:
> I don't think any language supports the empty key edge case in this way.
> The only language I know of that will let you get away with it is Perl,
> and in that case you get undef, not the empty string, and it's a warning
> if you have warnings o
On Mon, Mar 19, 2012 at 14:40, Alvaro Herrera
wrote:
>
> Excerpts from Alex Hunsaker's message of mié mar 07 01:08:25 -0300 2012:
>> The attached fixes it for me, It would be great if you could confirm that.
>
> Thanks -- applied to 9.1 and master.
Thanks!
--
Sent via pgsql-bugs mailing list (
On Thu, Mar 15, 2012 at 16:13, Bruce Momjian wrote:
> On Tue, Mar 06, 2012 at 09:08:25PM -0700, Alex Hunsaker wrote:
>> [ Calling a plperl trigger function from a plperl function ]
>>
>> Yeah, there were some optimization done for 9.1 to try and make calls
>> a bit fa
On Sat, Mar 3, 2012 at 12:19, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6511
> Logged by: Mark Murawski
> Email address: ma...@kobaz.net
> PostgreSQL version: 9.1.3
> Operating system: Linux - Debian Squeeze postgres 9.1 from backports
> De
On Sun, Dec 18, 2011 at 01:25, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6344
> Logged by: Kirill
> Email address: k_deni...@inbox.ru
> PostgreSQL version: 9.1.2
> Operating system: Linux Debian
> Description:
>
> plperl function:
> open(FI
On Fri, Nov 18, 2011 at 14:31, Tigran Mkrtchyan
wrote:
>
> On Fri, Nov 18, 2011 at 9:52 PM, Tomas Vondra wrote:
> > Anyway this definitely is not a bug,
>
> Still not convinced.
You are unlikely to convince anyone here otherwise... Its works that
way by design.
> [...] I don't think you will
On Fri, Oct 28, 2011 at 16:42, Mischa POSLAWSKY wrote:
> Composite types are converted to and from Perl hashes since commit
> REL9_1_ALPHA4~146 (Convert Postgres arrays to Perl arrays on PL/perl input
> arguments; 2011-02-17), but are not stringified as claimed by the commit
> message and release
On Sat, Oct 15, 2011 at 14:16, Rachael Nelson wrote:
> Attached is a tiny bit of top output (top.txt), the file being imported
> (postgres.sql.gz - about 32MB), and the perl module script that generates
Thanks. So the problem here seems to be postgres does not handle a
multi-hundred megabyte sing
On Sat, Oct 15, 2011 at 13:40, Rachael Nelson wrote:
> When I run this it does the same:
>
> psql test dev < postgres.sql
>
> the db is named test, connecting with the dev user.
I assume you meant to hit reply all :-)
If you can provide a self contained test case ideally in the form of
an .sql f
On Fri, Oct 14, 2011 at 21:43, Rachael wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6256
> Logged by: Rachael
> Email address: rulonr...@gmail.com
> PostgreSQL version: 9.11
> Operating system: Arch Linux
> Description: loading small file eat
On Wed, Sep 14, 2011 at 03:15, pasman wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6204
> Logged by: pasman
> Email address: pasma...@gmail.com
> PostgreSQL version: 9.1.0
> Operating system: WinXP sp3
> Description: Using plperl functions gen
On Sun, Sep 4, 2011 at 16:57, Tomas Vondra wrote:
> On 5 Září 2011, 0:27, Alex Hunsaker wrote:
>> On Sun, Sep 4, 2011 at 13:48, init-po fails for plperl due to invalid
>> xsubpp path wrote:
> So yes, it's almost the same as your results.
>
>
> Aha
On Sun, Sep 4, 2011 at 13:48, init-po fails for plperl due to invalid
xsubpp path wrote:
>
> Description: init-po fails for plperl due to invalid xsubpp path
> (contains ExtUtils)
> Details:
>
> When I try to prepare a fresh .pot file for plpgsql, it fails like this
>
> $ ./configure --ena
On Tue, Aug 2, 2011 at 00:25, Hitoshi Harada wrote:
> db1=# select * from test_xy order by x LIMIT 9223372036854775807 OFFSET 6;
[ ...]
> db1=# select * from test_xy order by x LIMIT pow(2, 63);
> ERROR: bigint out of range
> ERROR: bigint out of range
>
> Maybe a parser converts literal unexp
gt; > wrote:
>> > > On Mon, May 23, 2011 at 05:04:40PM -0600, Alex Hunsaker wrote:
>> > > ...
>> > >> Greg, can you confirm the attached fixes it for you?
>> > >
>> > > Yes, seems to have done the job, thank you.
>> >
>>
On Mon, May 23, 2011 at 20:08, Greg Sabino Mullane wrote:
> On Mon, May 23, 2011 at 05:04:40PM -0600, Alex Hunsaker wrote:
> ...
>> Greg, can you confirm the attached fixes it for you?
>
> Yes, seems to have done the job, thank you.
Thanks for testing!
[ Does a little dance to
On Mon, May 23, 2011 at 14:59, Greg Sabino Mullane wrote:
> I've not been able to duplicate this in a standalone script yet,
> but in the guts of Bucardo is a trigger function called validate_goat()
> that is giving this error on 9.1 HEAD, but not on previous versions:
>
> "Failed to add table "pu
On Sun, May 15, 2011 at 14:02, Robert Haas wrote:
>> Fixed in the attached plus added regression tests for both issues (use
>> strict; && Global symbol "$_TD" requires explicit package name, test
>> recursive trigger calls). Although Ill admit, given the point we are
>> in the release I could see
On Thu, May 5, 2011 at 06:51, Alvaro Herrera wrote:
> Excerpts from Alex Hunsaker's message of mié may 04 23:53:34 -0300 2011:
>
>> After playing with it a bit more I see 2 clear options:
>> 1) make $_TD global like %_SHARED. This should not cause any problems
>> as we make $_TD private via local(
On Wed, May 4, 2011 at 16:20, Alex Hunsaker wrote:
>
> This seems to be broken by
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=ef19dc6d39dd2490ff61489da55d95d6941140bf
> (Set up PLPerl trigger data using C code instead of Perl code.)
>
> Im not sure wha
On Tue, May 3, 2011 at 17:40, Greg Sabino Mullane wrote:
> This works in 9.0 but not in git/9.1 beta:
>
> CREATE FUNCTION wheredidmytdgo()
> RETURNS TRIGGER
> LANGUAGE plperlu
> AS
> $bc$
> use strict; use warnings;
> my $new = $_TD->{new};
> return;
> $bc$;
>
> The error is:
>
> ERROR:
On Thu, Jan 13, 2011 at 06:57, Julien Demoor wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5835
> Logged by: Julien Demoor
> Email address: jdem...@gmail.com
> PostgreSQL version: 9.0.2
> Operating system: Ubuntu Linux
> Description: PL/Python
On Thu, Oct 21, 2010 at 12:03, Alex Hunsaker wrote:
> Or if you just want the not null constraints:
> create table kittu1 (like kota1 including constraints);
Correction, the above should read: "Or, if you want check
constraints". Not null constraints are always copied, and inclu
On Thu, Oct 21, 2010 at 03:05, KOTAPATI.KRISHNAIAH
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5719
> Logged by: KOTAPATI.KRISHNAIAH
> Email address: kotapati.kris...@hotmail.com
> PostgreSQL version: PostgreSQL8.3.1
> Operating system: Microsoft Wi
On Wed, Oct 13, 2010 at 10:34, Robert Haas wrote:
> On Mon, Oct 11, 2010 at 4:24 PM, Igor wrote:
>> PostgreSQL version: 8.1
>> Operating system: CentOs 5
>> Description: not correct restrictions plperlu
>> Details:
>>
>> rights of functions on plperlu
>> lower than the user postgres
>>
On Mon, Oct 4, 2010 at 11:59, V.J. wrote:
> * Starting PostgreSQL 8.4 database server
> * The PostgreSQL server failed to start. Please check
> the log output:
> 2010-10-04 19:58:40 CEST FATAL: konnte auf private Schl?sseldatei
>>>server.key<< nicht zugreifen: No such file o
On Mon, Aug 9, 2010 at 01:30, Rene Novotny wrote:
> Thank's a lot
>
> with Activestate 64 bit perl 5.10 it works.
>
> It would be very desirable for plperl supporter to to add some plperl release
> notes with Postgresql
> production release for users to know , with what PERL distribution it work
On Fri, Aug 6, 2010 at 02:12, Adam Radlowski
wrote:
> PostgreSQL version: 8.4.4
> Operating system: Gentoo 64 bit (PSQL 8.4.4), Fedora 12 32 bit (PSQL
> 8.4.1)
> select round(any_numeric_field*something,2) from any_table;
> I get information, that the function dos not exist.
Can we get the exa
On Thu, Aug 5, 2010 at 12:25, Tom Lane wrote:
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
> ^
> HINT: No function matches the given name and ar
On Thu, Aug 5, 2010 at 00:13, Rene Novotny wrote:
>
> The following bug has been logged online:
> PostgreSQL version: 9.0 beta 4
> Operating system: Win 7 64 bit
> Description: cannot create language plperl;
> Details:
>
> ERROR: Could not load library
> c:/Program Files/PostgreSQL/9.0/li
On Wed, Aug 4, 2010 at 17:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> I dunno about anyone else but (a, ',' order by a) just looks weird.
>
> I suppose, but aren't you just focusing on the argument being constant?
Yes.
>> Or in other words, any tho
On Wed, Aug 4, 2010 at 16:33, Thom Brown wrote:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous. So I'm "for"
> now.
Ahh, Now I see why you were worried
On Wed, Aug 4, 2010 at 13:42, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>>> I think forcing an initdb might be more trouble than this wart is worth.
>
>> +1. I would not make this change unless we have to force
On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>&g
On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
> If we were a bit earlier in the 9.0 cycle I would suggest that this
> confusion is a sufficient reason to drop the one-argument form of
> string_agg. It's too late now though.
FWIW I think we can still change it. Isn't this type of issue part
of
On Wed, Aug 4, 2010 at 10:42, Robert Haas wrote:
> On Wed, Aug 4, 2010 at 10:53 AM, Shine wrote:
>> We would like to know if there is a workaround built into postgres by
>> setting some kind of COMPATIBILITY variable (similar to SQL SERVER 2005 /
>> 2008)...
>
> Sorry, there is no such mode...
H
On Sun, Aug 1, 2010 at 14:02, Karl Denninger wrote:
> (Whether Postgress 9's internal replication will solve this for me when it
> is released is something I'm not sure about - I think the answer is "no",
> since if I'm reading the docs correctly Postgres 9 requires that both master
> and slave b
On Sun, Aug 1, 2010 at 00:08, Karl Denninger wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5585
> Logged by: Karl Denninger
> Email address: k...@denninger.net
> PostgreSQL version: 8.4.4
> Operating system: FreeBSD 8.0
> Description: SSL probl
On Thu, Jul 29, 2010 at 20:01, yhou wrote:
> Operating system: windows 2000
> My program will use postgresal database, after start my program ,I find it
> hangs always, so I check the db log,and find these exception:
>
> 2010-07-27 14:08:22 EDT LOG: loaded library
> "$libdir/plugins/plugin_deb
On Mon, Jul 26, 2010 at 03:58, mile wrote:
> To reproduce this use the following function:
>
> create or replace function perl_shared() returns void as $$
> use strict;
> elog(INFO, $_SHARED{'stuff'});
> $_SHARED{'stuff'} = '1';
> for my $k (keys %_SHARED)
> {
> elog(INFO, $k);
> }
> $$ languag
On Fri, Jul 23, 2010 at 12:19, Daniel Grace wrote:
> Please see BUG #5564 -- I accidentally submitted this one before I was
> finished typing the details.
Ahh, sorry for the noise. I was just trolling for bug reports that
had no replys yet :-)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
On Fri, Jul 16, 2010 at 18:04, Daniel Grace wrote:
> However, in some circumstances Postgres will fail
How exactly?
this is what I get:
=> SELECT STRING_AGG(DISTINCT t::text order by t::text) FROM foo;
string_agg
abc
(1 row)
=> SELECT STRING_AGG(DISTINCT t::text order by t::text
On Fri, Jul 23, 2010 at 10:17, Milen wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5570
> Logged by: Milen
> Email address: m...@avangardsolutions.com
> PostgreSQL version: v9.0beta2
> Operating system: Linux
> Description: global hash %_SHARED
On Thu, Jul 22, 2010 at 11:21, Chris Browne wrote:
> 2. PostgreSQL Version 8.1 was the first version where AIX became
> sufficiently supported to allow it to be tested on a regular
> basis on the PostgreSQL Build Farm.
> http://pgbuildfarm.org/cgi-bin/show_status.pl
>
> There
On Thu, Jul 22, 2010 at 11:51, Denise Kanyuh wrote:
>
> Alex,
> Yes -- I am aware that we are on an old release --
>
> when you say - my hunch is
>
> they do not ship binaries for AIX (7.1).
>
>
> what binaries are you taking about --- we use the same installer and files
> on AIX 6.1 and it wor
On Thu, Jul 22, 2010 at 06:13, Denise Kanyuh wrote:
> PostgreSQL version: 8.0.15
[ BTW the latest version of 8.0 is 8.0.25, also note 8.0 is getting
EOL'ed within the next month or so, see
http://www.postgresql.org/about/news.1214 ]
> When trying to test our product which incorporates postgress
On Tue, May 25, 2010 at 11:26, Alex Hunsaker wrote:
> On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote:
>
>> The following reproducibly crashes Postgres 8.4.3 (segfault) inside
>> int84eq() on both Windows and Linux, but works just fine in 8.3.4:
>
> Hrm... Both work
On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote:
> The following reproducibly crashes Postgres 8.4.3 (segfault) inside
> int84eq() on both Windows and Linux, but works just fine in 8.3.4:
Hrm... Both work for me (8.4.3 and 8.4.4).
--
=> SELECT col1, col2 FROM t1 WHERE col1 IN ( SELECT * FRO
On Tue, May 11, 2010 at 12:42, Robert Haas wrote:
> I guess the question that comes to mind for me is how many other
> things fall into this category. We define a lot of symbols like int4
> and int32 that other people could also have defined, and I don't
> really want to s/^/pg/ all of them. If
On Mon, Mar 1, 2010 at 02:22, Oleg wrote:
> CREATE OR REPLACE FUNCTION "bug" () RETURNS pg_catalog.void AS
> $body$
> DECLARE
> row_test1 test1%rowtype;
> row_test2 test2%rowtype;
> BEGIN
> SELECT test1, chunk_id
> FROM test1 JOIN test2 ON(chunk.id = test2.chunk_id)
> LIMIT 1
>
On Thu, Feb 25, 2010 at 14:06, David E. Wheeler
wrote:
> On Feb 25, 2010, at 12:58 PM, Tim Bunce wrote:
>> There is one fairly good answer:
>>
>> Use a perl that's compiled to support multiplicity but not threads.
> That solves the problem with recursion or with $a and $b or both?
Yes ATM becaus
On Thu, Feb 25, 2010 at 13:03, Alex Hunsaker wrote:
> On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote:
>> Just don't break anything in 9.0 that relies on plperl please. :) To that
>> end, let me know when HEAD has something somewhat stable, and I'll
>>
On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote:
> Just don't break anything in 9.0 that relies on plperl please. :) To that
> end, let me know when HEAD has something somewhat stable, and I'll
> run some tests against it (e.g. Bucardo, which uses lots of plperl)
Defiantly, the goal is t
On Thu, Feb 25, 2010 at 12:31, David E. Wheeler
wrote:
> I think Tom meant, what sorts of changes to PostgreSQL do you think might
> solve the problem?
Here is what Tim said:
>Doesn't seem too icky. Basically plperl would need to save the values of
>PL_defstash, PL_incgv and PL_op_mask when a pl
On Thu, Feb 25, 2010 at 12:20, Tom Lane wrote:
> Alex Hunsaker writes:
>> 3) patch postgres to fix the recursive issue (What I'm leaning towards)
>> [ fixes both issues ]
>
> How exactly would you propose doing that?
Well that's the thing, probably by what I d
On Thu, Feb 25, 2010 at 11:04, David E. Wheeler
wrote:
> There seem to be no good answers here.
Yeah, Here is the thing I don't think we can fix 'safe' or even patch
perl to get recursive calls to work. Maybe Tim sees a way? We can
work around it in 9.0 with plperl.on_init. But breaking the ba
On Wed, Feb 24, 2010 at 22:01, Alex Hunsaker wrote:
> Ok I can get behind this. I did some testing and we could probably
> even store less than than that if we could do the equivalent of:
> Safe->share('::mksafefunc');
> pl_perl_createsub()
> Safe->unshare('
On Tue, Feb 23, 2010 at 15:54, Tim Bunce wrote:
> Doesn't seem too icky. Basically plperl would need to save the values of
> PL_defstash, PL_incgv and PL_op_mask when a plperl interpreter is
> initialized. And then local()'ly restore them in the plperl entry points.
> Should only be a few lines o
On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker wrote:
> On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
>> Seems entirely unacceptable.
> I think we will see if we can get this fixed on the Safe/perl side then.
BTW the trade off here is we revert back to sort { $a <=> $b } not
On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
>What you're saying, IIUC, is
> that if function A calls function B via a SPI command, and B wasn't
> executed previously in the current session, it would fail? Seems
> entirely unacceptable.
Yep, thats right :(. Thanks, thats exactly the kind of f
On Wed, Feb 24, 2010 at 19:17, Alex Hunsaker wrote:
> On Tue, Feb 23, 2010 at 15:23, Tim Bunce wrote:
>
>> I believe (but haven't yet confirmed) that the problem here is recursion.
>> This affects all versions of PostgreSQL.
> Ill keep digging.
Ok I understand now, ba
On Tue, Feb 23, 2010 at 15:23, Tim Bunce wrote:
> I believe (but haven't yet confirmed) that the problem here is recursion.
> This affects all versions of PostgreSQL.
Hrm... This seems to work for me in HEAD. It certainly breaks in 8.3.
Am I missing something?
$ bin/psql postgres
psql (9
On Tue, Feb 23, 2010 at 00:50, Alex Hunsaker wrote:
> On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote:
>> I'm inclined to stay with the same basic
>> implementation and just hack up the regexp some more to cope with 5.11's
>> more verbose -v output.
>
> And h
On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote:
> I'm inclined to stay with the same basic
> implementation and just hack up the regexp some more to cope with 5.11's
> more verbose -v output.
And here is a stab at that:
$ echo "This is perl, version 4.0" | sed -n 's/This is perl.*v[a-z
]*\([0-9]\.
On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote:
> Alex Hunsaker writes:
>> How about something like the below?
>
> I still think that this is optimizing the wrong thing. We care about
> the clarity of the message the user sees, not about how short or clean
> the Perl code
On Mon, Feb 22, 2010 at 14:17, Alex Hunsaker wrote:
> On Mon, Feb 22, 2010 at 13:07, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> ! perl_version_error=`$PERL -e 'use 5.00801;' 2>&1`
...
> How about something like the below?
Find attached on
On Mon, Feb 22, 2010 at 13:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> ! perl_version_error=`$PERL -e 'use 5.00801;' 2>&1`
>
> This is not a path towards an acceptable solution, as it effectively
> assumes what we are setting out to prove, namely that
On Mon, Feb 22, 2010 at 12:44, Alex Hunsaker wrote:
> On Mon, Feb 22, 2010 at 10:57, Jonathan wrote:
>> configure: using perl
>> configure: WARNING:
>> *** The installed version of Perl, /home/leto/bin/perl, is too old to use
>> with PostgreSQL.
>> *** Perl vers
On Mon, Feb 22, 2010 at 10:57, Jonathan wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5339
> Logged by: Jonathan "Duke" Leto
> Email address: jonat...@leto.net
> PostgreSQL version: master 0f50d482
> Operating system: CentOS 5.4 (Linux kernel 2.6.18)
On Fri, Feb 19, 2010 at 14:00, Tim Bunce wrote:
> On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote:
>> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
>> > It seems to me a more correct fix would be to require utf8; inside of
>> > the safe like we d
On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
> It seems to me a more correct fix would be to require utf8; inside of
> the safe like we do strict.
>
> Id favor this approach as if you have utf8 strings the likely hood
> that you want ::upgrade, ::downgrade, ::enc
On Fri, Feb 19, 2010 at 06:06, Tim Bunce wrote:
> I've got the patch to Safe ready but the more I think about it the more
> I think the right fix is for Safe to automatically fully load utf8.pm
> (and utf8_heavy.pl) and to always share SWASHNEW itself.
It seems cleaner if we could just share say
On Fri, Feb 19, 2010 at 02:30, Tim Bunce wrote:
> On Thu, Feb 18, 2010 at 11:32:38AM -0700, Alex Hunsaker wrote:
> > On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> >*PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
> >
> > Hrm... It seems to work for me in HE
On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> The key line is:
>
> *PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
Hrm... It seems to work for me in HEAD and AFAICS we dont have that
line. Did I just miss it? Or did you happen to fix it in another way
with your refactoring?
Another Idea tha
On Thu, Feb 18, 2010 at 02:20, wrote:
> $ psql -U foo -h 127.0.0.1 -f doesntwork.sql db
> Password for user foo:
> ERROR: invalid byte sequence for encoding "UTF8": 0xe46976
> HINT: This error can also happen if the byte sequence does not match the
> encoding expected by the server, which is co
On Thu, Jan 14, 2010 at 04:06, louis wrote:
> Arguments can't be passed to a plperl function
Yeah, this is a bug with safe 2.20 :( see
-http://rt.perl.org/rt3/Ticket/Display.html?id=72068
I would either try out this fix:
http://github.com/timbunce/Safe/commits/master.
Or downgrade to 2.19 for
On Thu, Nov 6, 2008 at 08:37, Alex Hunsaker wrote:
> On Thu, Nov 6, 2008 at 06:41, Tom Lane wrote:
>> "Alex Hunsaker" writes:
>>> On Wed, Nov 5, 2008 at 18:03, Andrew Gierth
>>> wrote:
>>>> Then explain why the problem goes away when you buil
On Tue, Aug 18, 2009 at 12:07, Tom Lane wrote:
> Throwing overflow errors doesn't seem very nice either, especially not
> for values that worked just fine before 8.4.
I just checked both 8.3.7 and 8.2.13 give:
# select '4817191.623 ms'::interval;
interval
--
-00:35:47.483648
(
On Tue, Aug 18, 2009 at 10:42, Tom Lane wrote:
> Alex Hunsaker writes:
>> It only happens if you have integer date times on... seems to have
>> gotten introduced by
>> http://archives.postgresql.org/pgsql-committers/2008-03/msg00406.php
>
> Uh, no, fsec_t was int32 be
On Tue, Aug 18, 2009 at 06:00, hubert depesz
lubaczewski wrote:
> Hi,
> tried on latest 8.5, and some 8.3:
> # select '4817191.623 ms'::interval;
> interval
> --
> -00:35:47.483648
> (1 row)
>
> I am pretty sure the answer is wrong. But why?
It only happens if you have integer
On Mon, Dec 29, 2008 at 15:07, Alex Hunsaker wrote:
> Namely it does not disable the rule...
> Enabling inside of the transaction seems to work though
Hrm the above turned out to be false... must have gotten confused when
testing with triggers
If i turn on RELCACHE_FORCE_RELE
Namely it does not disable the rule... Enabling inside of the
transaction seems to work though
Tried both CVS and 8.3.5...
create table trule (a int);
insert into trule (a) values (1);
create rule trule_rule as on update to trule do instead nothing;
update trule set a = 2;
UPDATE 0
begin;
ALTER
On Thu, Nov 6, 2008 at 09:00, Andrew Gierth <[EMAIL PROTECTED]> wrote:
> If it helps any, I've tracked down in the perl guts exactly why this
> happens:
Cool
> Notice, though, that without ithreads, the COP points directly to the
> stash, but with ithreads, it points instead to the _name_ of the
On Thu, Nov 6, 2008 at 09:03, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>
> Alex> I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374
>
> Feel free to add my explan
On Thu, Nov 6, 2008 at 06:41, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>>> Then explain why the problem goes away when you build perl
On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>
> >> Hmm ... so then why are we seeing a failure?
>
> [...]
> Alex> This is not a Safe bug
On Wed, Nov 5, 2008 at 11:14, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Gierth <[EMAIL PROTECTED]> writes:
>> Nice theory, but completely wrong: sort creates $a and $b in the
>> current package, not in main::.
>
> Hmm ... so then why are we seeing a failure?
Because Safe runs in a different nam
On Wed, Nov 5, 2008 at 10:54, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes:
>
> nathan> Completely untested speculation based on my knowledge of perl
> nathan> and a bit of reading:
>
> nathan> The reason you can't see $a and $b is that sor
On Tue, Nov 4, 2008 at 15:17, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Alex Hunsaker wrote:
>> Err no you're right its only builtins that use main:: sort being the
>> only one I know of off the top of my head... its a shame
>> PLContainer->
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
But by all means if you can come up with a robust way of allowing
>> the more traditional way of calling sort routines, send it in.
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> The other idea Ive been toying this is instead of calling reval we can
> just call Opcode::_safe_call_sv() something like the below:
Argh gmail probably ate the whitespace in the patch... see attached
plper
On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> We need to document that, and given that this exists I think we don't need
> to backpatch old versions.
Agreed.
> Beyond that, we need to be very careful with any "solution" that we don't
> upset the moderately fragile se
On Tue, Nov 4, 2008 at 12:43, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> It has something to do with anon subs not sure what...
It has to do with us returning the anonymous sub inside of the safe
and then calling the function outside of the safe (or at least in a
different namespac
On Tue, Nov 4, 2008 at 12:39, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Hrm works for me if I take out the elog from sort()
>
> Even more interesting, this variant *doesn't* work:
>
> regression=# create
On Tue, Nov 4, 2008 at 09:02, Jeff <[EMAIL PROTECTED]> wrote:
> I've ran into this interesting problem.
> It seems that while you can call sort() in a trusted plperl func you cannot
> access $a & $b which effectively makes it useless.
Hrm works for me if I take out the elog from sort()
create or
On Thu, Sep 25, 2008 at 4:05 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> A likely bet is that this is caused by use of uninitialized memory,
>> which happens to have garbage rather than zero
1 - 100 of 120 matches
Mail list logo
