On Fri, Jun 13, 2008 at 06:11:43PM -0700, Ralph Smith wrote:
> I get:
> ERROR: cannot change return type of existing function
> HINT: Use DROP FUNCTION first.
Don't use CREATE OR REPLACE for the second one. The OR REPLACE is
trying to replace a function of the same name.
A
--
Andrew Sulliva
I never did get an answer to this.
I get:
ERROR: cannot change return type of existing function
HINT: Use DROP FUNCTION first.
** Error **
ERROR: cannot change return type of existing function
SQL state: 42P13
Hint: Use DROP FUNCTION first.
When I try to:
CREATE OR REPLAC
Hi. I'm trying to automate the updating of a database. This entails
creating the new database from scratch (which takes a long time), under a
different name, say mydb_tmp, and once this new database is ready, doing a
"hot swap", i.e. renaming the existing database to something like
mydb_20080613
@craig
i am on mac os x 10.5 and i installed via macports using robby russel
pg install guide.
here is the initdb...
Init your new PostgreSQL database with: initdb -D pgdata
Start up PostgreSQL with: pg_ctl -D pgdata -l pgdata/psql.log start
Create a new database with: createdb argon_development
I have found in most instances if you leave the services window open
the installer will fail to install (or upgrade) the postgres service.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Tom Lane wrote:
> "James B. Byrne" <[EMAIL PROTECTED]> writes:
> > GiT works by compressing deltas of the contents of successive versions of
> > file
> > systems under repository control. It treats binary objects as just another
> > object under control. The question is, are successive (compres
"Henry - Zen Search SA" <[EMAIL PROTECTED]> writes:
> On Fri, June 13, 2008 7:05 pm, Tom Lane wrote:
>> The memory overhead per subtransaction is
>> not zero, though I think it's fairly small if you don't have any
>> triggers pending as a result of the insert.
> Two triggers are fired for each ins
"James B. Byrne" <[EMAIL PROTECTED]> writes:
> I have recently had to teach myself how to use git and the thought came to me
> that this tool might provide a fairly low setup cost way of passing pg_dumps
> over the network to our off site data store. Think Rsync, but on a file
> content basis; jus
James B. Byrne wrote:
I have recently had to teach myself how to use git and the thought came to me
that this tool might provide a fairly low setup cost way of passing pg_dumps
over the network to our off site data store. Think Rsync, but on a file
content basis; just the content diff gets trans
On Fri, June 13, 2008 7:05 pm, Tom Lane wrote:
> How soon is "bang"?
I'll run it again and post back.
> The memory overhead per subtransaction is
> not zero, though I think it's fairly small if you don't have any
> triggers pending as a result of the insert.
Two triggers are fired for each inser
Windows 2000 Prof. Used upgrade option, not full install.
I upgraded my 8.3.1 to 8.3.3. Looks like all went ok except I had no
psql.exe in my bin dir.
I searched for it & found it in
C:\WINNT\Installer\{B823632F-3B72-4514-8861-B961CE263224} dir.
It is the 8.3.3 version. When I copied it to m
I was browsing the postgresql download site, but I wasn't able to find
the source RPM for 8.3.3. Is it available on the site?
Thanks,
Kevin
James B. Byrne wrote:
> GiT works by compressing deltas of the contents of successive versions of file
> systems under repository control. It treats binary objects as just another
> object under control. The question is, are successive (compressed) dumps of
> an altered database sufficiently sim
I have recently had to teach myself how to use git and the thought came to me
that this tool might provide a fairly low setup cost way of passing pg_dumps
over the network to our off site data store. Think Rsync, but on a file
content basis; just the content diff gets transmitted.
GiT works by co
"Henry - Zen Search SA" <[EMAIL PROTECTED]> writes:
> One other thing: the docs mention that functions use cursors
> automatically to prevent OOM errors on large selects (as in my case).
> Well, the second part of my function does this:
> FOR rec in SELECT * FROM bigtable
> LOOP
>...begin/in
On Mon, June 2, 2008 6:53 pm, Tom Lane wrote:
> I don't think your problem has anything to do with dblink per se.
> The repeated begin/exception blocks are apparently managing to leak
> some memory per iteration. I can't tell whether this represents
> a known (and perhaps already fixed) bug; it ve
16 matches
Mail list logo
