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('::mksafefunc');
On 2nd thought this ba
On Feb 24, 2010, at 7:19 PM, Tom Lane wrote:
>> ISTM the easiest and safest fix would be to not allow recursive plperl
>> creations. You could still call plperl functions within functions,
>> just not if they are not defined. This limitation really blows
>
> That's the understatement of the mon
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
I wrote:
> That doesn't in itself explain a problem with building from the
> alpha tarball though. Is it possible there's a clock skew problem
> in the tarball's file timestamps?
I poked around in the alpha4 tarball and didn't find clock skew.
What I found out was that there's some fundamental fu
Alex Hunsaker writes:
> 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 <=>
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
working. That is if
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
Alex Hunsaker writes:
> ISTM the easiest and safest fix would be to not allow recursive plperl
> creations. You could still call plperl functions within functions,
> just not if they are not defined. This limitation really blows
That's the understatement of the month. What you're saying, IIUC,
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, basically the problem is (as
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
Bruce Momjian writes:
> Tom Lane wrote:
>> Anybody know what Oracle's to_timestamp does?
> The old thread reported Oracle returned an error;
> http://archives.postgresql.org/pgsql-bugs/2009-06/msg00100.php
Well, nothing's likely to get done about it for 9.0. Maybe we should
add a TODO ite
Tom Lane wrote:
> Bruce Momjian writes:
> > FYI, this behavior now returns:
>
> > test=> select to_timestamp('20096010','MMDD');
> > to_timestamp
> >
> > 2013-12-18 00:00:00-05
> > (1 row)
>
> > which doesn't have the :30 but is still odd.
Bruce Momjian writes:
> FYI, this behavior now returns:
> test=> select to_timestamp('20096010','MMDD');
> to_timestamp
>
>2013-12-18 00:00:00-05
> (1 row)
> which doesn't have the :30 but is still odd.
I don't think the behavio
FYI, this behavior now returns:
test=> select to_timestamp('20096010','MMDD');
to_timestamp
2013-12-18 00:00:00-05
(1 row)
which doesn't have the :30 but is still odd. I don't see any value
checking in to_timestamp.
--
The following bug has been logged online:
Bug reference: 5346
Logged by: Maximiliano Salazar
Email address: maxisala...@hotmail.com
PostgreSQL version: 8.2
Operating system: Windows 7 Ultimate 64 Bits
Description:PostgresSQL ODBC 64 bits download
Details:
Hello.
I
I wrote:
>>> I can see two reasonable ways to address this:
>>>
>>> * Change the ltree test to reject only ARR_NDIM > 1.
>>>
>>> * Drop the ARR_NDIM check altogether, and let it search any sort of
>>> array.
>>>
>>> I'm leaning to #2 myself. However, there are probably other places with
>>> the
Joe Conway writes:
> Related to this I have noticed in recent weeks on my own development
> machine that "make install" takes *much* longer, but only sporadically,
> due to the docs building.
This might be related to Peter's changes to the docs build procedure.
The way things work now is that if
On 02/24/2010 08:43 AM, Lou Picciano wrote:
> Tom -
>
> Didn't realize I was arm waving - was I? (Sometimes email falls well
> short...)
>
> We've managed a build of PostgreSQL 9.0-alpha4 - nice! However, the #
> make install command apparently(?) hiccups
> on a dependency on Jade (we ain't u
Bruce Momjian writes:
> Tom Lane wrote:
>>> I can see two reasonable ways to address this:
>>>
>>> * Change the ltree test to reject only ARR_NDIM > 1.
>>>
>>> * Drop the ARR_NDIM check altogether, and let it search any sort of
>>> array.
>>>
>>> I'm leaning to #2 myself. However, there are pr
Tom -
Didn't realize I was arm waving - was I? (Sometimes email falls well short...)
We've managed a build of PostgreSQL 9.0-alpha4 - nice! However, the # make
install command apparently(?) hiccups
on a dependency on Jade (we ain't usin' it!)
Here's the exact make install output:
-
Tom Lane wrote:
> Bruce Momjian writes:
> > Was this ever addressed?
>
> No, it doesn't look like the code's been changed. I was looking for
> some comments about which to do:
>
> >> I can see two reasonable ways to address this:
> >>
> >> * Change the ltree test to reject only ARR_NDIM > 1.
>
Bruce Momjian writes:
> Was this ever addressed?
No, it doesn't look like the code's been changed. I was looking for
some comments about which to do:
>> I can see two reasonable ways to address this:
>>
>> * Change the ltree test to reject only ARR_NDIM > 1.
>>
>> * Drop the ARR_NDIM check al
2010/2/24 Patrick Weimer :
> Hi,
>
> the error message of the subject is my big problem, log entrys:
>
> 2010-02-24 12:22:25 LOG: XX000: could not receive data from client:
> Unknown winsock error 10061
> 2010-02-24 12:22:25 LOCATION: pq_recvbuf, pqcomm.c:738
> 2010-02-24 12:22:25 LOG: 08P01: un
Lou Picciano writes:
> Not sure it's exactly a bug, but in attempting a compile of
> PostgreSQL-9.0alpha, we are getting a choke on jade (don't have jade on this
> system)
> Can the config script test for jade or, better yet, allow an option to turn
> off build of documentation?
Would you sh
"Zoltan Kovacs" writes:
> I would like to create a database using SQL_ASCII encoding, but it is not
> allowed for a normal user, only for the postgres user.
There is an exception that will allow superusers to do that, but it's
not a good idea for them either. The problem is not the encoding per
Was this ever addressed?
---
Tom Lane wrote:
> "Alan Pinstein" writes:
> > ... hierarchy @> ARRAY(select hierarchy from
> > feature where description ilike '%pool%this%') ...
>
> > EXPECTED BEHAVIOR:
> > - return 0 rows
Toni Helenius writes:
> I actually managed to trace this so that I can reproduce the crashing simply
> with an empty table created as in attachment. If I delete the table,
> everything is fine. The table can be empty and pg_dump still crashes. This is
> really weird...
Works for me --- I ran t
Not sure it's exactly a bug, but in attempting a compile of
PostgreSQL-9.0alpha, we are getting a choke on jade (don't have jade on this
system)
Can the config script test for jade or, better yet, allow an option to turn off
build of documentation?
Hi,
the error message of the subject is my big problem, log entrys:
2010-02-24 12:22:25 LOG: XX000: could not receive data from client:
Unknown winsock error 10061
2010-02-24 12:22:25 LOCATION: pq_recvbuf, pqcomm.c:738
2010-02-24 12:22:25 LOG: 08P01: unexpected EOF on client connection
2010-
The following bug has been logged online:
Bug reference: 5345
Logged by: Zoltan Kovacs
Email address: kov...@particio.com
PostgreSQL version: 8.3.9-0lenny1
Operating system: Debian Linux 5.0.4
Description:non-administrator users cannot create databases with
special en
Oleg Serov writes:
> When it could be fixed?
Oh, it is fixed, but I forgot to reply to this thread about it.
Sorry about that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On Thu, Feb 18, 2010 at 12:51:04AM +0530, janandith jayawardena wrote:
> When building libecpg there are errors like,
>
> Error 1 error LNK2019: unresolved external symbol _PGTYPESdate_from_asc
> referenced in function _ECPGget_data data.obj libecpg
>
> I see PGTYPESdate_from_asc in src/interfac
When it could be fixed?
On Thu, Feb 11, 2010 at 9:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2010/2/10 Oleg Serov :
>>> Somebody will fix this bug or not?
>
>> I'm not sure whether this is a bug.
>
> Yeah, I think it is. The problem is that exec_move_row is taking too
> many shortcuts with
33 matches
Mail list logo
