Hi all.
I would like to study the protocol for large object operations
(lo_read, lo_write,...) between the front-end and back-end.
I've found this
http://www.postgresql.org/docs/8.1/static/protocol.html, but it looks
like it has no message specific for large object...
How is it implemented in
Hi,
I have something strange here, with Postgresql 8.1.4 under Linux ES 4,
installed from the PG Group binaries:
If I run this script:
CREATE OR REPLACE FUNCTION foo() RETURNS void
AS
$$
my $val;
sub init
{
$val = @_[0];
elog(NOTICE, 1: @_[0]\n);
Jim Nasby wrote:
On Jun 21, 2006, at 7:42 AM, H.J. Sanders wrote:
The last 15 years we also used Informix and we never, never had to
unload/load
the database because of an upgrade.
Perhaps somebody knows how they do the trick?
Do they provide a migration/upgrade utility?
In the case
On Fri, Jun 23, 2006 at 11:33:42AM +0200, Philippe Lang wrote:
Am I missing something maybe? It sounds like a bug with lexical variables to
me...
I think what's happening is that sub init is created once with $val
referencing the lexically-scoped $val from sub foo's first invocation.
When you
Rhys Stewart wrote:
hi all,
something is not adding up. the following query is taking a long time
to run.(its still running right now)
select distinct on (prem) prem, num, addy, mynum,myad,ff.address,
matchtype,
the_geom
from daily.recheck2, _sp_myparcels ff
where
prem not in (
select
On Fri, Jun 23, 2006 at 07:49:19AM -0600, Michael Fuhr wrote:
This behavior isn't specific to PL/Perl. A standalone Perl program
exhibits the same behavior, so you might find a better explanation
in a Perl-specific forum like the comp.lang.perl.misc newsgroup.
If you run it standalone with
SQL Server had a nifty feature here. You could simply toss a SELECT
statement at the end of a trigger of sproc and the results would be
returned.
This in effect made a table the potential return type of all commands,
which could be exploited very powerfully.
Do the hackers have any
Marco Bizzarri [EMAIL PROTECTED] writes:
I would like to study the protocol for large object operations
(lo_read, lo_write,...) between the front-end and back-end.
I've found this
http://www.postgresql.org/docs/8.1/static/protocol.html, but it looks
like it has no message specific for large
Greetings everyone,Since we've started using the pg_autovacuum table we've come to realize that keeping OID values between our database dumps is critical. I've been doing some testing using the pg_dump command with the --oids option. For some reason, it doesn't seem like the the OID values are
I like to make sure the vacuum takes place during off peak times, which
is why I don't use autovacuum.
Jim Nasby wrote:
On Jun 22, 2006, at 7:12 PM, Joseph Shraibman wrote:
I'm running a 8.0 database. I have a very large log table that is
rarely updated or deleted from. The nightly vacuum
We've PostgreSQL database, with SQL_ASCII or LATIN1 encoding. We would
like to migrate them to UNICODE. Is there some contributed/available
script, or this is something we should do at hand?
I had a similar problem migrating from 7.4 to 8.1 and wanting to
go from sql_ascii to utf8. I did the
Dylan Hansen [EMAIL PROTECTED] writes:
Since we've started using the pg_autovacuum table we've come to
realize that keeping OID values between our database dumps is
critical. I've been doing some testing using the pg_dump command
with the --oids option.
--oids is only meant to preserve
On 6/22/06 2:57 PM, Jim Nasby [EMAIL PROTECTED] wrote:
If nothing else, you should bring it up on -hackers and ask to have
this added as a TODO. It seems like a worth-while addition to pg_dump/
restore to me...
Thanks for the suggestion.
To answer another of your emails in this thread... a
Hi Tom, thanks for your reply.On 23-Jun-06, at 11:17 AM, Tom Lane wrote:--oids is only meant to preserve OIDs within user tables; it never hasand never will preserve OIDs for system-catalog entries.So just to clarify, the table's OID itself will never be preserved, but the data inside the table
Hi Tom.
Thanks for your suggestion, this was my choice, after I was unable to
find any reference.
On 6/23/06, Tom Lane [EMAIL PROTECTED] wrote:
Marco Bizzarri [EMAIL PROTECTED] writes:
I would like to study the protocol for large object operations
(lo_read, lo_write,...) between the
Jim Nasby [EMAIL PROTECTED] writes:
My RFE: When vacuuming a table, pg should try to vacuum the primary key
first. If that results in 0 recovered entries, then assume the table has
no
updates/deletes and skip the rest of that table.
That makes no sense. Vacuum starts by scanning
Scott, Ken and Tim,
Thanks for the assistance, I appreciate the advice.
Scott,
The example of
select id1 = nextval(somesequence)
could work for me. I have multiple users with our GUI and imagine I
could use transaction protection to ensure no duplicates between
selecting and incrementing
Tom Lane wrote:
Clarence [EMAIL PROTECTED] writes:
I have a completely idle postgresql system (all backends idle, none
in transaction); every time I attempt to vacuum a particular table,
it hangs after a while.
...
In the system error log there is this line:
could not write block
So far, here are the candidates: Andromeda, Lazarus, and Rekall.
I was probably fairly inarticulate in my first post, but none of these
seem to meet my criteria for automatic generation of forms based on the
database definition. Most of the above frameworks have a good deal
more functionality
nuno wrote:
hi, there. i'm trying to write a SQL statement which does the following
things.
1. checks if data already exists in the database
2. if not, insert data into database otherwise skip.
Check this thread :
http://archives.postgresql.org/pgsql-general/2005-10/msg01787.php
Clarence [EMAIL PROTECTED] writes:
Tom Lane wrote:
I seem to recall having fixed a bug like this in the past. What PG
version are you running?
We're running 8.0.3
Um. Extract from the 8.0.5 CVS logs:
2005-12-08 14:19 tgl
* src/backend/: postmaster/bgwriter.c,
21 matches
Mail list logo
