[BUGS] ERROR: cache lookup failed for function 0
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 IMMUTABLE STRICT;
CREATE CAST (name[] AS text) WITH FUNCTION namearray_text(name[]) AS
IMPLICIT;
CREATE OR REPLACE FUNCTION namearray_eq( name[], name[] )
RETURNS bool
AS 'SELECT $1::text = $2::text;'
LANGUAGE sql IMMUTABLE STRICT;
CREATE OPERATOR = (
LEFTARG= name[],
RIGHTARG = name[],
NEGATOR= <>,
PROCEDURE = namearray_eq
);
SELECT '{foo}'::name[] <> '{bar}'::name[];
ROLLBACK;
If you comment out the NEGATOR line, the error is changed to the more
useful
ERROR: operator is not unique: name[] <> name[]
I'm assuming that, if you did this for 8.3 (which has name[]
comparison operators in core, so it'd have to be an operator with some
other type), you'd get the same useless error.
Ideally, in the situation where a NEGATOR (or commutator, too?) is
specified but has not actually been defined, you'd get an error such as:
ERROR: operator not defined: name[] <> name[]
Thanks,
David
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ERROR: cache lookup failed for function 0
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 worth it?
Thanks,
David
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] WARNING: uuid.h: present but cannot be compiled
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 \ --with-openssl --with-pam --with-krb5 --with-libxml --with-ldap --with- ossp-uuid \ --with-libs=/usr/local/lib --with-includes=/usr/local/include -- prefix=/usr/local/pgsql Configure generates this warning: checking uuid.h presence... yes configure: WARNING: uuid.h: present but cannot be compiled configure: WARNING: uuid.h: check for missing prerequisite headers? configure: WARNING: uuid.h: see the Autoconf documentation configure: WARNING: uuid.h: section "Present But Cannot Be Compiled" configure: WARNING: uuid.h: proceeding with the preprocessor's result configure: WARNING: uuid.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## configure: WARNING: ## ## checking for uuid.h... yes I guess it's finding Apple's uuid.h and not OSSP's? Do I need to set some other environment variable to tell PostgreSQL where to find the ossp uuid include? BTW, I moved OSSP's uuid.h because it caused conflicts with other apps that just need Apple's uuid.h. This is a known issue for OSSP UUID: http://cvs.ossp.org/tktview?tn=164 Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] WARNING: uuid.h: present but cannot be compiled
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't bother setting CPPFLAGS in addition). Duh, I already had --with-includes for another directory. Thanks. I guess it's finding Apple's uuid.h and not OSSP's? Yeah, that's what it looks like, although it's odd that that fails to compile. Yeah, seems odd… Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] WARNING: uuid.h: present but cannot be compiled
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 find it. I put it in /usr/local/include and ran configure with --with-includes=/usr/local/include and it didn't find it. RhodiumToad said on IRC that it's looking for "ossp/uuid.h", so I tried putting it in /usr/local/include/ossp/ and ran configure with the same --with-include and it still didn't find it. So at this point, I'm unable to figure out how to get configure to find and use the OSSP uuid header. :-( 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: WARNING: ossp/uuid.h: present but cannot be compiled configure: WARNING: ossp/uuid.h: check for missing prerequisite headers? configure: WARNING: ossp/uuid.h: see the Autoconf documentation configure: WARNING: ossp/uuid.h: section "Present But Cannot Be Compiled" configure: WARNING: ossp/uuid.h: proceeding with the preprocessor's result configure: WARNING: ossp/uuid.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## configure: WARNING: ## ## checking for ossp/uuid.h... yes Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] WARNING: uuid.h: present but cannot be compiled
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 matter where I put uuid.h, configure doesn't seem to find it. I put it in /usr/local/include and ran configure with --with-includes=/usr/local/include and it didn't find it. RhodiumToad said on IRC that it's looking for "ossp/ uuid.h", so I tried putting it in /usr/local/include/ossp/ and ran configure with the same --with-include and it still didn't find it. So at this point, I'm unable to figure out how to get configure to find and use the OSSP uuid header. :-( 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: WARNING: ossp/uuid.h: present but cannot be compiled configure: WARNING: ossp/uuid.h: check for missing prerequisite headers? configure: WARNING: ossp/uuid.h: see the Autoconf documentation configure: WARNING: ossp/uuid.h: section "Present But Cannot Be Compiled" configure: WARNING: ossp/uuid.h: proceeding with the preprocessor's result configure: WARNING: ossp/uuid.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## configure: WARNING: ## ## checking for ossp/uuid.h... yes Oh, and despite that warning, I am in fact able to build and install the OSSP UUID contrib module. So I've no idea what that warning is about. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] WARNING: uuid.h: present but cannot be compiled
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: WARNING: ossp/uuid.h: present but cannot be compiled Why not? There should be compiler messages in config.log. Dunno. Here's the log for the latest build: config.log.gz Description: GNU Zip compressed data Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] WARNING: uuid.h: present but cannot be compiled
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-aliasing -fwrapv -I/usr/local/include/libxml2 - I/usr/local/include conftest.c >&5 In file included from conftest.c:98: /usr/local/include/ossp/uuid.h:94: error: conflicting types for 'uuid_t' /usr/include/unistd.h:133: error: previous declaration of 'uuid_t' was here Oh, that old canard. So it's just http://cvs.ossp.org/tktview?tn=164 again. Thanks, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Termination When Switching between PL/Perl and PL/PerlU
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):
postgres=# create or replace function wtf(text) returns text language plperl as
'shift';
CREATE FUNCTION
Time: 151.054 ms
postgres=# select wtf('hey');
ERROR: invalid byte sequence for encoding "UTF8": 0x00
CONTEXT: PL/Perl function "wtf"
postgres=# create or replace function wtf(text) returns text language plperlu
as 'shift';
CREATE FUNCTION
Time: 41.255 ms
postgres=# select wtf('hey');
wtf
-
hey
(1 row)
Time: 0.523 ms
postgres=# create or replace function wtf(text) returns text language plperl as
'shift';
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5277: plperl can't get args properly
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 > postgresql? This is the issue I asked about on -hackers last month, and which I finally tracked down yesterday to a bug in Safe.pm 2.20. Tim Bunce has since fixed it. Report here: http://rt.perl.org/rt3/Public/Bug/Display.html?id=72068 In the short run, you can downgrade to Safe.pm 2.19 and the problem will go away. Or just use PL/Perlu, which doesn't rely on Safe.pm. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [Tigerlead] [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
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 that PostgreSQL would work without > changes. Hrm. I don't have this bug with Safe 3.19, FWIW. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [Tigerlead] [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
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 method without a problem. Oh, so 2.19 is less secure in that regard, yes? David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
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 month. 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. Exactly what I was thinking. This "fix" is right out. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
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 can find a -commiter willing to commit it
> sooner. But I'm dubious. I think the feeling between me and Tim is
> patching postgres is a last resort... Maybe if its to fix both sort
> {} and this it might be worth it. (That's at least how I parsed what
> you said :) ). Ill see if I can figure something out via straight
> Safe tonight.
I think Tom meant, what sorts of changes to PostgreSQL do you think might solve
the problem?
Best,
David
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
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 will revert to Safe 1.19 behaviour > because the side effects of the change in 2.20 are too severe for it to > be left enabled by default. 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. There seem to be no good answers here. David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
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. >> >> There seem to be no good answers here. > > There is one fairly good answer: > > Use a perl that's compiled to support multiplicity but not threads. > That avoids the sort bug and, as an extra bonus, gives plperl a > significant speed boost. That solves the problem with recursion or with $a and $b or both? I'm happy to rebuild Perl without threads, since I'm not going to use Padre after all. But that won't help the millions who rely on package-supplied Perls, which are nearly always threaded AFAICT. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
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 security when *not* under threads as well? I find this all very confusing, frankly. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
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 will revert to Safe 1.19 behaviour > because the side effects of the change in 2.20 are too severe for it to > be left enabled by default. 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. There seem to be no good answers here. David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5356: citext not acting like case insensitive search
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, Windows 7 x64 > Description:citext not acting like case insensitive search > Details: > > When we run the following query, we return no results. > > Select citystateinfoid from iss.citystateinfo where cityname = > 'JACKSONVILLE' and statecode = 'FL'; > > However this does work > > Select citystateinfoid from iss.citystateinfo where cityname = > 'Jacksonville' and statecode = 'FL' > > The second query is how the data is actually stored. I've already forwarded > our ddl to david wheeler. Michael managed to fix this issue by moving citext to the "public" schema. The question is, why would citext operators work in the public schema but not when they're in some other schema? Is `=` resolving to `TEXT = TEXT` if the "iss" schema isn't in the search path? Michael, does this work? Select citystateinfoid from iss.citystateinfo where cityname iss.= 'JACKSONVILLE' and statecode iss.= 'FL'; Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5356: citext not acting like case insensitive search
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 Michael would like. Yes, I suspect that he can solve his problem by adding the iss schema to search_path. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bug or regression in plpgsql vs word window, your choice
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 > ought to get an official word, and make sure it is documented as a regression > for future folks if that's the case. I ran into the same thing with the use of a variable named "verbose". This is due to Tom porting PL/pgSQL to use the core lexer. So now it's more consistent about the use of reserved words. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #3905: configure cannot find ossp UUID libs and/or includes
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 seem to have been installed: david=# select uuid_generate_v1(); ERROR: function uuid_generate_v1() does not exist LINE 1: select uuid_generate_v1(); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. david=# \q trigger% ll /usr/local/pgsql/share/contrib/*.sql | grep uuid trigger% ll /usr/local/pgsql/lib | grep uuid I don't know if there's any nice way to make configure avoid including while testing uuid.h. Personally I think libuuid's attempt to usurp typenames that may be defined by the system headers is hopelessly broken, and that they'd be better off doing the #define's the other way around, ie, make the underlying real names of *their* typedefs different. It is just not acceptable that their header doesn't work if is included first. Thanks. See: http://cvs.ossp.org/tktview?tn=164 Best, David ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3905: configure cannot find ossp UUID libs and/or includes
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/contrib/*.sql | grep uuid trigger% ll /usr/local/pgsql/lib | grep uuid Best David ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3905: configure cannot find ossp UUID libs and/or includes
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-8.3RC2/contrib/uuid-ossp trigger# make sed 's,MODULE_PATHNAME,$libdir/uuid-ossp,g' uuid-ossp.sql.in >uuid- ossp.sql gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith - Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict- aliasing -I. -I../../src/include -I/usr/local/include/libxml2 -I/usr/ local/include -c -o uuid-ossp.o uuid-ossp.c ar crs libuuid-ossp.a uuid-ossp.o ranlib libuuid-ossp.a gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith - Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict- aliasing -bundle -multiply_defined suppress uuid-ossp.o -L../../src/ port -L/usr/local/lib -L/usr/local/lib -luuid -bundle_loader ../../src/ backend/postgres -o libuuid-ossp.0.0.so rm -f libuuid-ossp.0.so ln -s libuuid-ossp.0.0.so libuuid-ossp.0.so rm -f libuuid-ossp.so ln -s libuuid-ossp.0.0.so libuuid-ossp.so trigger# make install /bin/sh ../../config/install-sh -c -m 644 ./uninstall_uuid-ossp.sql '/ usr/local/pgsql/share/contrib' /bin/sh ../../config/install-sh -c -m 644 uuid-ossp.sql '/usr/local/ pgsql/share/contrib' /bin/sh ../../config/install-sh -c -m 755 libuuid-ossp.0.0.so '/usr/ local/pgsql/lib/uuid-ossp.so' trigger# psql -U postgres /usr/local/pgsql/share/contrib/uuid-ossp.sql postgres psql: warning: extra command-line argument "postgres" ignored psql: FATAL: database "/usr/local/pgsql/share/contrib/uuid-ossp.sql" does not exist trigger# psql -U postgres -f /usr/local/pgsql/share/contrib/uuid- ossp.sql postgres SET CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION trigger# psql -U postgres trigger% psql Welcome to psql 8.3RC2, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit david=# select uuid_generate_v1(); uuid_generate_v1 -- 2bcce5e4-cdf0-11dc-b6a6-0017f2c2618f (1 row) Thanks, David ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Drop one-argument string_agg? (was Re: [BUGS] string_agg delimiter having no effect with order by)
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; > ^ 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. You might need > to add explicit type casts. > > It's not perfect (I don't think it's practical to get the HINT to > read "Put the ORDER BY at the end" ;-)) but at least it should > get people pointed in the right direction when they do this. It confuses the shit out of me. It says "string_agg(text)" doesn't exist when that clearly is not the name of the function you've called. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] Drop one-argument string_agg? (was Re: [BUGS] string_agg delimiter having no effect with order by)
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. You might >>> need to add explicit type casts. >>> >>> It's not perfect (I don't think it's practical to get the HINT to >>> read "Put the ORDER BY at the end" ;-)) but at least it should >>> get people pointed in the right direction when they do this. >> >> It confuses the shit out of me. It says "string_agg(text)" doesn't exist >> when that clearly is not the name of the function you've called. >> > > What function name do you believe was called? The message says: string_agg(f1 order by f1, ',') That looks like string_agg(text, text) or string_agg(anyelement, text). Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] Drop one-argument string_agg? (was Re: [BUGS] string_agg delimiter having no effect with order by)
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 to order the aggregate input rows. OH!. Wow, weird. I never noticed that. >> It confuses the shit out of me. It says "string_agg(text)" doesn't exist >> when that clearly is not the name of the function you've called. > > Well, maybe we need to expend some more sweat on the error message then. > But this patch was still a prerequisite thing, because without it there > is no error that we can complain about. Yeah, understood. Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] Drop one-argument string_agg? (was Re: [BUGS] string_agg delimiter having no effect with order by)
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) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5616: psql Doesn't Change Log files on \c
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 in my .psqlrc: \set HISTFILE ~/.psql_history- :DBNAME This is great, except when I change databases in a session: % psql foo foo % \c bar You are now connected to database "bar". SELECT true; The last statement will be logged to ~/.psql_history-foo when it should go to ~/.psql_history-bar. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5846: Segfault Postgresql Built with --lib-libedit-preferred
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: Been meaning to report this for a while. * Build PostgreSQL on Mac OS X using --with-libedit-preferred. * Connect to the server from psql * type "\d feat", where "" is the tab key, an attempt to autocomplete * Output for me: try=# \d mls_fepsql(69838) malloc: *** error for object 0x6: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug zsh: abort psql corp_schema YOW! I *assume* it's something funky with libedit, but in case you can't reproduce it with just the libedit option, I configure my server with: ./configure --with-libedit-preferred --with-bonjour --with-perl PERL=$PERL \ --with-openssl --with-pam --with-krb5 --with-libxml --with-ldap \ --with-ossp-uuid --with-includes=/usr/local/include \ --enable-integer-datetimes --with-zlib \ --with-libs=/usr/local/lib Best, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5846: Segfault Postgresql Built with --lib-libedit-preferred
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 ago. Anyone got a test case that doesn't involve building PostgreSQL? Thanks, David -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
