Re: During dump: function not found

oops. Too late to use that option; but thanks!

Andrew Gould

--- Justin Clift <justin(at)postgresql(dot)org> wrote:
> Hi Andrew,
>
> These functions were indeed created by PgAdmin. It
> seems to create
> tables, functions, triggers and views (maybe rules
> too, not sure) going
> by the name pgadmin_xxx and pga_xxx
>
> I'm pretty sure from looking at PgAdmin 7.1.0
> recently it has a menu
> option to remove it's tables and other constructs
> from a target database
> by itself. You might just want to run that instead
> of doing it
> yourself/
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
>
> Andrew Gould wrote:
> >
> > During a pg_dump, I got the following messages:
> >
> > Notice: function "pgadmin_get_rows" is not dumped.
> > Reason: return type name (oid 87589805) not found.
> > Notice: function "pgadmin_get_sequence" is not
> dumped.
> > Reason: return type name (oid 87589772) not found.
> >
> > Does this simply mean that these functions will
> not be
> > available if I restore from the dump file? Will
> these
> > messages haunt me down the road in other ways?
> >
> > I'm assuming (dangerous, I know) that these
> functions
> > were created by PgAdmin rather than being a part
> of
> > PostgreSQL. I deleted all tables and views named
> > pgadmin* and am trying to weed out everything
> created
> > by PgAdmin.
> >
> > Thanks,
> >
> > Andrew Gould
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute
> with Yahoo! Messenger
> > http://phonecard.yahoo.com/
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> >
> http://www.postgresql.org/users-lounge/docs/faq.html
>
> --
> "My grandfather once told me that there are two
> kinds of people: those
> who work and those who take the credit. He told me
> to try to be in the
> first group; there was less competition there."
> - Indira Gandhi

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
>From pgsql-general-owner(at)postgresql(dot)org Wed Aug 22 13:46:55 2001
Received: from server (client-sp03-85.speedex.net [208.33.90.85])
by postgresql.org (8.11.3/8.11.4) with ESMTP id f7MHJZP72238
for <pgsql-general(at)postgresql(dot)org>; Wed, 22 Aug 2001 13:19:35 -0400 (EDT)
(envelope-from will(at)serensoft(dot)com)
Received: from will by server with local (Exim 3.12 #1 (Debian))
id 15ZbfB-0005Nf-00
for <pgsql-general(at)postgresql(dot)org>; Wed, 22 Aug 2001 12:19:33 -0500
Date: Wed, 22 Aug 2001 12:19:33 -0500
From: will trillich <will(at)serensoft(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Re: Syntax for wildcard selection
Message-ID: <20010822121933(dot)B15403(at)serensoft(dot)com>
Mail-Followup-To: pgsql-general(at)postgresql(dot)org
References: <jasont(at)indigoindustrial(dot)co(dot)nz> <200108160011(dot)RAA01695(at)scotts(dot)mynetwork(dot)net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200108160011(dot)RAA01695(at)scotts(dot)mynetwork(dot)net>; from scott(at)pacificnet(dot)net on Wed, Aug 15, 2001 at 05:11:28PM -0700
X-Archive-Number: 200108/679
X-Sequence-Number: 14069

On Wed, Aug 15, 2001 at 05:11:28PM -0700, Scott Holmes wrote:
> It would seem that my database has unseen garbage in the field being queried.
> On further testing I find that
>
> select *
> from people
> where peopcode LIKE 'AB%AH%'
> order by peopcode;
>
> works, however
>
> select *
> from people
> where peopcode LIKE 'AB%AH'
> order by peopcode;
>
> does not. I do have nine records that meet the above criteria and are found
> if the pattern ends with '%' but not without it.

here's my guess --

you probably used

create table people (
...
peopcode CHAR(...)
...
);

instead of

peopcode VARCHAR(...)

the "char" type pads with blanks (ascii 32 in latin1 encoding)
to fill the size of the field. "varchar" truncates the data
only if the data exceeds the field size.

so
like "%pat"
will match fields ENDING with "pat" -- for varchar that's
usually at the end of the data; for char, that's at the last few
characters as speficied by the length of the field.

thus, for a field containing
"stuff like this "
a LIKE "%this" would not match, but a LIKE "%this%" would, and so
would LIKE "%this ".

--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)

will(at)serensoft(dot)com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!