Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
It seems to me that it has always been implicitly assumed around here
that the MERGE command would be a substitute for a MySQL-like REPLACE
functionality. After rereading the spec it seems that this is not the
case. MERGE always
Hi,
I'm just a little bit confused because I expected postgresql to be able
t connect by prior but as I have seen it is not. :-(
Are there any plans to support this in the main distribution? If have
found a patch to porstgres but I don't want to apply any patches but
only use the vanilla
Gregory Maxwell wrote:
So it turned out that he didn't... Is this a sign that we need to
include a versioning symbol in SOs so we can give a nice clear error
message module foo compiled for PostgreSQL 8.0.2 this is PostgreSQL
8.1.
I think this would rarely work in practice. For example,
On Sat, Nov 12, 2005 at 12:28:48PM +0100, Peter Eisentraut wrote:
I think this would rarely work in practice. For example, during the
elog-ereport transition, any module compiled against the wrong server
would immediately get an unresolved symbol: elog/ereport before you
can run your nice
Postresql 8.1.0:
I was looking what does vacuumlo provide in contrib, but it seems there is a
problem with messages given by this program:
[EMAIL PROTECTED] regress]$ /usr/bin/vacuumlo
vacuumlo: missing required argument: database name
Try 'vacuumlo -?' for help.
[EMAIL PROTECTED] regress]$
Thank you, this is very handy.
I'd like to understand why the result of this query is different
from the number of Postgres processes reported by `ps`.
(The query returns 8, ps shows 11)
One process is really postmaster, the others seem to be doing some
house chores: stats buffer process and
Martijn van Oosterhout kleptog@svana.org writes:
So the idea is to force failure when it would otherwise succeed, not
just for the pretty error messages but for stability of the system.
Exactly. Peter's right that we'd not always get a nice error message
--- but it's not hard to figure out
Brusser, Michael [EMAIL PROTECTED] writes:
One process is really postmaster, the others seem to be doing some
house chores: stats buffer process and stats collector process.
Do they actually use connections,
No.
regards, tom lane
---(end of
I thought of an alternative approach to the library version problem:
what about taking a leaf from the usual shared library versioning
approach, ie, put the version number into the library file name?
So instead of loading, say, plpgsql.so we'd insist on loading
plpgsql.so.8.2.
This would avoid
On Sat, Nov 12, 2005 at 10:47:35AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
I would be in favour if storing the CATALOG_VERSION in the pg_finfo
struct and rejecting anything that doesn't match.
Not sure that CATALOG_VERSION is an amazingly useful thing to
Martijn van Oosterhout kleptog@svana.org writes:
Sure, CATALOG_VERSION isn't that useful, but it's the only thing in the
header files that gives any kind of indication what version you're
compiling against. PG_VERSION is a string, which diminishes its
usefulness considerably.
How so? All we
On Sat, Nov 12, 2005 at 11:18:51AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Sure, CATALOG_VERSION isn't that useful, but it's the only thing in the
header files that gives any kind of indication what version you're
compiling against. PG_VERSION is a string,
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Nov 12, 2005 at 11:18:51AM -0500, Tom Lane wrote:
How so? All we care about is being able to (1) compare for equality,
and (2) print out something useful in error messages. I claim that
PG_VERSION does #1 equally well and #2 better.
On Sat, Nov 12, 2005 at 12:03:00PM -0500, Tom Lane wrote:
That would be attractive if we could get it to happen without the
assumption that the library uses PG_FUNCTION_INFO_V1 ... but if it still
needs that assumption, it doesn't seem like much of an improvement.
It's not always easy for
Martijn van Oosterhout kleptog@svana.org writes:
If we don't like imposing link time constraints, we could require
people to include:
#ifdef PG_MAGIC_BLOCK
PG_MAGIC_BLOCK;
#endif
I was hoping to avoid forcing source-code changes, but something like
that might be the best solution. Anyone
An occasionally asked question is How can I find out how many rows
a cursor will return? to which the answer is Fetch them all. But
what about a way to get the planner's estimate? Would anybody find
that useful? Does the code below look close to being correct?
test= EXPLAIN SELECT * FROM
Michael Fuhr [EMAIL PROTECTED] writes:
An occasionally asked question is How can I find out how many rows
a cursor will return? to which the answer is Fetch them all. But
what about a way to get the planner's estimate? Would anybody find
that useful?
Given how far off it frequently is, I
On Sat, Nov 12, 2005 at 12:44:23PM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
If we don't like imposing link time constraints, we could require
people to include:
#ifdef PG_MAGIC_BLOCK
PG_MAGIC_BLOCK;
#endif
I was hoping to avoid forcing source-code
On Sat, Nov 12, 2005 at 01:50:20PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
An occasionally asked question is How can I find out how many rows
a cursor will return? to which the answer is Fetch them all. But
what about a way to get the planner's estimate? Would
Martijn van Oosterhout kleptog@svana.org writes:
I was hoping to avoid forcing source-code changes, but something like
that might be the best solution. Anyone think it's unreasonable?
Alternativly, you could make it optional for a release (print warning
that magic block wasn't found). Next
Yann,
I am working on the standard WITH syntax for recursive query support and hope to get it into 8.2.
On 11/12/05, Yann Michel [EMAIL PROTECTED] wrote:
Hi,I'm just a little bit confused because I expected postgresql to be ablet connect by prior but as I have seen it is not. :-(Are there any
Tom Lane wrote:
Brusser, Michael [EMAIL PROTECTED] writes:
One process is really postmaster, the others seem to be doing some
house chores: stats buffer process and stats collector process.
Do they actually use connections,
No.
But note that in 8.1, autovacuum does.
--
Alvaro Herrera
Hi,
On Sat, Nov 12, 2005 at 03:27:32PM -0500, Jonah H. Harris wrote:
Yann,
I am working on the standard WITH syntax for recursive query support and
hope to get it into 8.2.
Fine! Looking forward to that!
Cheers,
Yann
---(end of broadcast)---
Hi,
I'm using PG_DUMP for backing up a postgres 7.4 database. As I have
seen, the pg_dump aquires a table lock while dump the table's content.
What will happen, if I have a basic table and several inherited tables.
Will the PG_DUMP tool only aquire locks on the inherited tables or on
the
That's GREAT news, hope you can make it to 8.2 .. it will be really a good hit
On 11/13/05, Yann Michel [EMAIL PROTECTED] wrote:
Hi,
On Sat, Nov 12, 2005 at 03:27:32PM -0500, Jonah H. Harris wrote:
Yann,
I am working on the standard WITH syntax for recursive query support and
hope to
Most of the people who have thought about this have figured that the
right solution involves a single index spanning multiple tables (hence,
adding a table ID to the index entry headers in such indexes). This
fixes the lookup and entry problems, but it's not any help for the
Tom Lane wrote:
On the other hand, it'd be relatively easy for clueless lusers to
defeat; I can readily imagine someone copying foo.so.8.2 to foo.so.8.3
when the backend complained that it couldn't find the latter. So
maybe it's not what we want.
Hmm...but isn't the version number also
27 matches
Mail list logo
