Howdy,
I ran into this error on 8.2 a while ago, and just figured out what
was causing it. Here's a quick example on 8.2:
BEGIN;
-- Compare name[]s more or less like 8.3 does.
CREATE OR REPLACE FUNCTION namearray_text(name[])
RETURNS TEXT AS 'SELECT textin(array_out($1));'
LANGUAGE sql IMMUT
On Oct 25, 2008, at 05:35, Tom Lane wrote:
Seems to be fixed in HEAD:
regression=# SELECT '{foo}'::name[] <> '{bar}'::name[];
ERROR: operator is only a shell: name[] <> name[]
LINE 1: SELECT '{foo}'::name[] <> '{bar}'::name[];
Great. Is it something that could be backported, or is it not wor
I'm building 8.4beta1 on Mac OS X 10.5.6. I have ossp-uuid installed
with its includes in /usr/local/include/ossp-uuid. I'm building
PostgreSQL like so:
export CPPFLAGS="-I/usr/local/include/ossp-uuid"
./configure --with-libedit-preferred --with-bonjour --with-perl PERL=/
user/local/bin/perl
On Apr 17, 2009, at 7:08 AM, Tom Lane wrote:
"David E. Wheeler" writes:
I'm building 8.4beta1 on Mac OS X 10.5.6. I have ossp-uuid installed
with its includes in /usr/local/include/ossp-uuid.
Well, then you would need --with-includes=/usr/local/include/ossp-uuid
(don&#
On Apr 17, 2009, at 10:21 AM, David E. Wheeler wrote:
On Apr 17, 2009, at 9:22 AM, David E. Wheeler wrote:
So does it not know to look in /usr/local/include/ossp-uuid when
it's looking for uuid.h?
Tried a few more things. No matter where I put uuid.h, configure
doesn't seem to
On Apr 17, 2009, at 10:47 AM, David E. Wheeler wrote:
On Apr 17, 2009, at 10:21 AM, David E. Wheeler wrote:
On Apr 17, 2009, at 9:22 AM, David E. Wheeler wrote:
So does it not know to look in /usr/local/include/ossp-uuid when
it's looking for uuid.h?
Tried a few more things. No m
On Apr 17, 2009, at 11:08 AM, Tom Lane wrote:
"David E. Wheeler" writes:
I take that back. It can find it in the ossp subdirectiry, as
RhodiumToad said, but it can't compile it:
checking ossp/uuid.h usability... no
checking ossp/uuid.h presence... yes
configure: WARNI
On Apr 17, 2009, at 11:28 AM, Alvaro Herrera wrote:
Dunno. Here's the log for the latest build:
configure:13224: checking ossp/uuid.h usability
configure:13241: gcc -no-cpp-precomp -c -O2 -Wall -Wmissing-
prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-
labels -fno-strict-al
Found in 8.4.2, replicated in HEAD. Steps:
1. Create PL/Perl function.
2. Run it.
3. Create same function with PL/PerlU
4. Run it.
5. Create same function again with PL/Perl
6. Boom.
Example on HEAD built today (ignore the error from the plperl version, that's
the issue I'm trying to fix locally
Tom Lane writes:
> "louis" writes:
> > Arguments can't be passed to a plperl function
>
> [ scratches head... ] Works for everybody else. I have to suppose
> there's something broken about your libperl, or plperl somehow got
> built wrong. How did you build or come by your copies of perl and
On Feb 18, 2010, at 10:09 AM, Tim Bunce wrote:
> It took a depressingly large number of intense hours to work out what
> was going on and then more to try to work out a relatively clean solution.
>
> The underlying problem is in perl and Safe but sadly there's no
> reasonable way to fix Safe such
On Feb 19, 2010, at 1:13 AM, Tim Bunce wrote:
>> Hrm. I don't have this bug with Safe 3.19, FWIW.
>
> That's because Safe 1.19 (which I presume you meant) doesn't execute
> closures 'inside' the Safe compartment. So when the regex executes at
> runtime the C code looks up the utf8::SWASHNEW metho
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 Feb 25, 2010, at 11:29 AM, Alex Hunsaker wrote:
> Well that's the thing, probably by what I described below that. Namely
> get something working for 9.1 and after we know its good and solid see
> if we can back patch it. Unfeasible? If its really really simple and
> straight forward maybe we
On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>> That's two unacceptable alternatives, you need to find a third one.
>> I think most people will have no trouble settling on "do not update
>> to Safe 2.2x" if you don't offer a better solution than these.
>
> I believe the next version of Safe wil
On Feb 25, 2010, at 12:58 PM, Tim Bunce wrote:
>> Which means losing sort $a <=> $b again, alas. Such was always the
>> case in the past, so that might be an okay tradeoff to get recursive
>> calls working again, but I certainly hope that Safe can be updated in
>> the near future to give us both.
On Feb 25, 2010, at 1:08 PM, Alex Hunsaker wrote:
>> That solves the problem with recursion or with $a and $b or both?
>
> Yes ATM because we only kick in the extra security if you are on
> threads... Its a bit of a kludge in Safe. I know Tim wants to rectify
> that...
By adding the extra secur
On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>> That's two unacceptable alternatives, you need to find a third one.
>> I think most people will have no trouble settling on "do not update
>> to Safe 2.2x" if you don't offer a better solution than these.
>
> I believe the next version of Safe wil
On Mar 1, 2010, at 9:15 AM, Michael Gould wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5356
> Logged by: Michael Gould
> Email address: mgo...@intermodalsoftwaresolutions.net
> PostgreSQL version: 8.4.2
> Operating system: Windows 2008 R2 Server, W
On Mar 1, 2010, at 10:25 AM, Tom Lane wrote:
> Not sure if there is anything we can do to make this much nicer.
> Removing the implicit cast seems like a cure worse than the disease,
> particularly because it would result in throwing a "no such operator"
> error rather than actually doing what Mic
On Mar 16, 2010, at 9:20 PM, Robert Treat wrote:
> The problem is with the variable name window; once I changed it things worked
> fine. Now, Window is supposed to be a reserved word, so I am not necessarily
> expecting it to work any more, but this code works fine in 8.4., so I figured
> I
>
On Jan 27, 2008, at 18:43, Tom Lane wrote:
Oh, it finds it all right. It's just complaining (not incorrectly)
that
uuid.h fails when included after . AFAICT this is just
cosmetic, since we don't use it that way. If you go ahead and build
then everything should be fine.
Hrm. It doesn't see
On Jan 28, 2008, at 10:08, Tom Lane wrote:
david=# select uuid_generate_v1();
ERROR: function uuid_generate_v1() does not exist
Did you run the module's SQL script?
It was not put into /usr/local/pgsql/share/contrib. Neither of these
had any output:
trigger% ll /usr/local/pgsql/share/co
On Jan 28, 2008, at 13:52, Tom Lane wrote:
Hmph ... works for me on a reasonably stock OS X 10.5.1 machine.
You did do "make" and "make install" in the contrib subtree,
right?
No. I assumed that that's what --with-ossp-uuid would do for me. But
yeah, that does work:
trigger# cd postgresql-
On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
> Applied to HEAD and 9.0. The mistaken case will now yield this:
>
> 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;
On Aug 5, 2010, at 11:42 AM, Thom Brown wrote:
>>> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
>>> ^
>>
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>>
>>> HINT: No function matches the given name and argument types.
On Aug 5, 2010, at 11:45 AM, Tom Lane wrote:
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>
> Yeah, the whole point of the thread: that's not a call of a two-argument
> aggregate. It's a call of a one-argument aggregate, using a two-column
> sort key
On Aug 5, 2010, at 12:16 PM, Tom Lane wrote:
> HINT: No aggregate function matches the given name and argument
> types. Perhaps you misplaced ORDER BY; ORDER BY must appear after all
> regular arguments of the aggregate.
+1
David
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
The following bug has been logged online:
Bug reference: 5616
Logged by: David E. Wheeler
Email address: da...@kineticode.com
PostgreSQL version: 8.4
Operating system: Mac OS X 10.6.4
Description:psql Doesn't Change Log files on \c
Details:
I have this
The following bug has been logged online:
Bug reference: 5846
Logged by: David E. Wheeler
Email address: da...@kineticode.com
PostgreSQL version: 9.0.1
Operating system: Mac OS X 10.6.6
Description:Segfault Postgresql Built with --lib-libedit-preferred
Details
On Jan 24, 2011, at 3:49 PM, Tom Lane wrote:
> This has been reported before, most recently last week. It's a libedit
> bug (and yes it's been reported to Apple, but another complaint directed
> there wouldn't hurt).
Oh. I've probably complained to them myself. First noticed it quite some time
31 matches
Mail list logo
