On Tue, Sep 23, 2008 at 10:38 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dean Rasheed" <[EMAIL PROTECTED]> writes:
>> CREATE TABLE foo(a int, b int);
>> CREATE VIEW foo_v AS SELECT * FROM foo;
>> CREATE RULE foo_r AS ON INSERT TO foo_v DO INSTEAD INSERT INTO foo
>> VALUES(NEW.a, NEW.b);
>> INSERT I
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 zeroes in it the second
> time through.
Yep both DCH_MC and DCH_US were going past the end of the string
because t
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
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 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 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 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 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 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: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 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 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 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 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 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 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
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 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
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 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 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 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 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, 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, 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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: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 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 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 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
The following bug has been logged online:
Bug reference: 3973
Logged by: Alex Hunsaker
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: Linux
Description:pg_dump using inherited tables do not always restore
Details:
create table junk
On Wed, Feb 20, 2008 at 3:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > create table junk (val integer not null, val2 integer);
> > create table junk_child () inherits (junk_1);
> > alter table junk_child
> It seems much more restrictive than necessary, plus it does nothing
> for the check-constraint case. My recollection of the previous
> discussion about how to fix this was that we needed to add an inhcount
> column to pg_constraint, and add entries for not-null constraints (at
> least inh
(Sorry if duplicates show up this is the third time ive posted this in
the past 10 hours, Im assuming it got dropped because of the
attachments)
Problem: Apparently random segfaults apparently query agnostic, seem
to be more frequent when a pg_dump is running
The most frequent query it segfault
On Tue, Mar 11, 2008 at 10:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > Problem: Apparently random segfaults apparently query agnostic, seem
> > to be more frequent when a pg_dump is running
>
> Hmm, se
FYI right now Im trying:
Author: tgl
Date: Sat Feb 2 22:26:17 2008 +
Fix WaitOnLock() to ensure that the process's "waiting" flag is reset after
erroring out of a wait. We can use a PG_TRY block for this, but
add a comment
explaining why it'd be a bad idea to use it for any ot
Oops we actually use DBI->prepare_cached() not DBI->prepare() which to
my understanding should be roughly equivalent to (because of
Apache::DBI):
prepare query ;
begin;
execute query;
commit;
(next page load)
begin;
execute query;
commit;
I can turn that off and only use DBI->prepare() as a t
On Wed, Mar 12, 2008 at 12:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Now personally, I am much more interested in *reproducing* the problem
> than merely dodging it. I can understand if you just need a workaround
> yesterday, but please see if you can get a reproducible test case ...
>
>
On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > the mean time here is a new backtrace I just got (lord knows how... it
> > seems to be as soon as I stop trying to make it cras
On Wed, Mar 12, 2008 at 9:22 AM, Greg Sabino Mullane <[EMAIL PROTECTED]> wrote:
ommits.
>
> Are you sure you are calling DBI->connect *after* the Apache children
> are created?
Yes.
Major problems like this can happen if not. The use of
> prepare_cached() may be adding to the problem as well,
On Wed, Mar 12, 2008 at 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> >> If you say "none of my stuff is changing any sc
On Wed, Mar 12, 2008 at 10:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > Here is what im trying right now with no success:
>
>
> > my $sth = $db->prepare_cached('select * from jun
Hrm still no luck.
I created a snapshot of the database, moved it onto another server so
i could play with it...
Ive tried using just prepare on the console using the query that fails:
prepare worker (bigint, bigint) as select w.worker_id, w.worker_id as
printerid, w.worker, w.alias, coalesce(w.
On Wed, Mar 12, 2008 at 1:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > Perhaps my simple updates are not enough for analyze to
> > invalidate the query plan? Should I be doing inserts/deletes or just
>
err that should be (forgot the username, password placeholders)
> my $db = DBI->connect('dbi:Pg:dbname=test;', '', '', {'pg_server_prepare'=>1,
> 'pg_prepare_now'=>1}) || die "could not connect: $!";
> $db->do('create table junk (junk text, junk_id int);');
> $db->do('create sequence junk_seq;'
On Wed, Mar 12, 2008 at 1:59 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> $db->do("create or replace function junk_func(int) returns integer as
> 'select junk_id from junk where junk_id = \$1;' language 'sql' stable
> strict;");
>
Another
On Wed, Mar 12, 2008 at 6:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> This patch should fix it ...
>
> regards, tom lane
Excellent seems to have fixed the problem. Thanks!
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscripti
On Fri, Mar 28, 2008 at 4:07 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
>
> On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> > Attached is a WIP patch I have been playing with in my spare time. It
> > should take care
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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
1 - 100 of 120 matches
Mail list logo
