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 so
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
lock-against-schema-m
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
>
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 parent-ta
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)
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.
--
Alv
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
Martijn van Oosterhout 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 release requi
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?
On Sat, Nov 12, 2005 at 12:44:23PM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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
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
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 p
Martijn van Oosterhout 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 think it's unr
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 p
Martijn van Oosterhout 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.
> I was thin
On Sat, Nov 12, 2005 at 11:18:51AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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 diminis
Martijn van Oosterhout 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 care about is
On Sat, Nov 12, 2005 at 10:47:35AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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 use.
> I think
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
"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
Martijn van Oosterhout 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 "unresolved symbo
Yann Michel <[EMAIL PROTECTED]> writes:
> 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?
There's some work being done to implement the SQL-standard recu
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 stats
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]$ /usr
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
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,
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" postg
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 op
28 matches
Mail list logo
