On Thu, May 04, 2006 at 01:32:45 -0400,
Greg Stark [EMAIL PROTECTED] wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
On Thu, May 04, 2006 at 00:05:16 -0400,
Greg Stark [EMAIL PROTECTED] wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
Whereas it shouldn't be hard to prove
On Thu, May 04, 2006 at 01:13:20 -0400,
Tom Lane [EMAIL PROTECTED] wrote:
I think it's a fair point that we could allow SELECT DISTINCT x ORDER BY
foo(x) if foo() is stable, but that does not imply that sorting by x is
interchangeable with sorting by foo(x). foo = abs is a trivial
Bruno Wolff III [EMAIL PROTECTED] writes:
... it would be OK to rewrite
SELECT DISTINCT x ORDER BY foo(x)
as
SELECT DISTINCT ON (foo(x), x) x ORDER BY foo(x)
This assumes that x = y implies foo(x) = foo(y), which is something
that's not necessarily the case, mainly because a datatype's =
Hello,
I'm finishing my career in computer engineering. To finish that I've
to develop a new implementation of R*-tree. My teacher Prof. Dr.
Seeger, http://dbs.mathematik.uni-marburg.de/Home/People/Professor has
already one done, now he wants me to add it to PostgreSQL using Gist.
Now that gist
On Thu, 4 May 2006, fernando esparza wrote:
Hello,
I'm finishing my career in computer engineering. To finish that I've
to develop a new implementation of R*-tree. My teacher Prof. Dr.
Seeger, http://dbs.mathematik.uni-marburg.de/Home/People/Professor has
already one done, now he wants me to
For you it will be easy to understand GiST interface looking into
src/backend/access/gist/gistproc.c. It implements RTree.
fernando esparza wrote:
Hello,
I'm finishing my career in computer engineering. To finish that I've
to develop a new implementation of R*-tree. My teacher Prof. Dr.
On Wed, 2006-05-03 at 16:15 -0400, Tom Lane wrote:
This is motivated by Jim Buttafuoco's recent gripe about not being
able to connect while a DROP DATABASE is in progress:
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00074.php
...
If dropdb() takes such a lock before it checks
On Tue, 2006-05-02 at 15:01 -0400, Alvaro Herrera wrote:
Just noticed a typo in newly added ginxlog.c. I don't have line
numbers, but in ginRedoSplit() it reads:
PageSetLSN(rpage, lsn);
PageSetTLI(lpage, ThisTimeLineID);
MarkBufferDirty(rbuffer);
Comparing the lists of functions exported by libpq and those declared
by libpq-fe.h turns up a fair number of descrepancies. Most of these
functions are declared by internal header files. For clarity I think we
should clarify the situation, either explicity declare them for
external users, or stop
Gentlepeople,
Now that the patch is out for keeping the last
autovacuum/vacuum/analyze/autoanalyze
timestamp in the stats system is pending, what's the consensus view on
what, if any,
logging changes are wanted for autovacuum?
I have the time and inclination to cut code quickly for it.
On Thu, May 04, 2006 at 02:39:33 -0400,
Tom Lane [EMAIL PROTECTED] wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
... it would be OK to rewrite
SELECT DISTINCT x ORDER BY foo(x)
as
SELECT DISTINCT ON (foo(x), x) x ORDER BY foo(x)
This assumes that x = y implies foo(x) = foo(y),
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-05-03 at 16:15 -0400, Tom Lane wrote:
If dropdb() takes such a lock before it checks for active
backends, then the connection sequence can look like this:
Many people never CREATE or DROP databases. They just do everything in
the default
Hi,
I'm trying to write a PL/Python function which is to be called from a
rule. I'd need pass the OLD and NEW tuple records to the function.
Unfortunately that does not work: 'pl/python functions cannot take type
record'.
What I have figured out by reading the source code: OLD and NEW are
pseudo
[EMAIL PROTECTED] (Larry Rosenman) writes:
Gentlepeople,
Now that the patch is out for keeping the last
autovacuum/vacuum/analyze/autoanalyze
timestamp in the stats system is pending, what's the consensus view on
what, if any,
logging changes are wanted for autovacuum?
I have the
I don't know about anyone else, but the only time I look at that mess is
to find poor tuple/table or tuple/index ratios and other indications
that vacuum isn't working as well as it should be.
How about this instead:
Log when the actual autovacuum_vacuum_scale_factor (dead space cleaned
up) was
Rod Taylor wrote:
I don't know about anyone else, but the only time I look at that mess
is to find poor tuple/table or tuple/index ratios and other
indications that vacuum isn't working as well as it should be.
How about this instead:
Log when the actual autovacuum_vacuum_scale_factor
On Thu, 2006-05-04 at 11:25 -0500, Larry Rosenman wrote:
Rod Taylor wrote:
I don't know about anyone else, but the only time I look at that mess
is to find poor tuple/table or tuple/index ratios and other
indications that vacuum isn't working as well as it should be.
How about this
Bruno Wolff III [EMAIL PROTECTED] writes:
Thanks for pointing that out. I should have realized that this was the same
(or at least close to) issue I was thinking would be a problem initially, but
then I started thinking that '=' promised more than it did and assumed that
x = y implies foo(x)
Martijn van Oosterhout kleptog@svana.org writes:
Comparing the lists of functions exported by libpq and those declared
by libpq-fe.h turns up a fair number of descrepancies. Most of these
functions are declared by internal header files. For clarity I think we
should clarify the situation,
Markus Schiltknecht [EMAIL PROTECTED] writes:
What exactly are pseudo types?
See
http://developer.postgresql.org/docs/postgres/extend-type-system.html
Why can PLs not handle pseudo-types?
No one's done the work to figure out which ones are sensible to support
and then add the logic needed to
On Wed, May 03, 2006 at 02:25:54PM -0400, Tom Lane wrote:
On Tue, May 02, 2006 at 05:49:33PM -0500, Jim C. Nasby wrote:
Back in the discussion of this someone had mentioned capturing all the
info that you'd get from a vacuum verbose; dead tuples, etc. What do
people think about that? In
On Thu, May 04, 2006 at 08:46:54AM +0100, Simon Riggs wrote:
On Tue, 2006-05-02 at 15:01 -0400, Alvaro Herrera wrote:
Just noticed a typo in newly added ginxlog.c. I don't have line
numbers, but in ginRedoSplit() it reads:
PageSetLSN(rpage, lsn);
PageSetTLI(lpage,
Greg Stark [EMAIL PROTECTED] writes:
Hm. This goes back to the earlier conversation about whether = should ever be
true for two objects that aren't, well, equal. I thought there was some
consensus at the time that sorting should impose a superficial ordering on
items that compare equal but
Jim C. Nasby [EMAIL PROTECTED] writes:
On Wed, May 03, 2006 at 02:25:54PM -0400, Tom Lane wrote:
Isn't this already dealt with by contrib/pg_freespacemap?
AFAIK that does nothing to tell you how much space is desired by
relations.
I thought the latest patch arranged to expose per-relation
On Thu, May 04, 2006 at 12:37:48PM -0400, Rod Taylor wrote:
On Thu, 2006-05-04 at 11:25 -0500, Larry Rosenman wrote:
Rod Taylor wrote:
I don't know about anyone else, but the only time I look at that mess
is to find poor tuple/table or tuple/index ratios and other
indications that
On Thu, May 04, 2006 at 01:20:32PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Wed, May 03, 2006 at 02:25:54PM -0400, Tom Lane wrote:
Isn't this already dealt with by contrib/pg_freespacemap?
AFAIK that does nothing to tell you how much space is desired by
On Thu, May 04, 2006 at 12:47:39PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Comparing the lists of functions exported by libpq and those declared
by libpq-fe.h turns up a fair number of descrepancies. Most of these
functions are declared by internal header
Tom Lane wrote:
Why can PLs not handle pseudo-types?
No one's done the work to figure out which ones are sensible to support
and then add the logic needed to support them.
PL/Java will handle the RECORD type correctly. I'm just finalizing a new, more flexible,
type mapping implementation for
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, May 04, 2006 at 12:47:39PM -0400, Tom Lane wrote:
Already done no? (at least on the platforms where we know how to
restrict it)
These functions are all in the exports.txt. I was just wondering if we
wanted to cut that list down any
Thomas Hallgren [EMAIL PROTECTED] writes:
PL/Java will handle the RECORD type correctly. I'm just finalizing a new,
more flexible,
type mapping implementation for PL/Java and it would be easy to add support
for more pseudo
types too. But what others would make sense?
If you've got
Jim C. Nasby [EMAIL PROTECTED] writes:
After CVS-upping... yes, both lastpagecount and nextpage are now
included. But unfortunately the README says next to nothing about what
they mean...
Yeah, this needs a bit of work ... will have at it.
regards, tom lane
Moving to -hackers...
On Thu, May 04, 2006 at 09:17:31AM -0700, Stephan Szabo wrote:
On Thu, 4 May 2006, Rich Doughty wrote:
I have a foreign key constraint that I'd like to alter. I'd rather not
drop and re-create it due to the size of the table involved. All I need
to do is add an ON
Natives getting restless... :)
Any plans for a release?
- Forwarded message from Bruno Wolff III [EMAIL PROTECTED] -
On Tue, May 02, 2006 at 14:20:03 -0400,
Matthew T. O'Connor matthew@zeut.net wrote:
Hey all, I was just wondering if there were any plans to get 8.1.4
release in the
On Thu, May 04, 2006 at 03:21:56PM -0400, Tom Lane wrote:
AFAIK, everything that is in exports.txt was put there for a reason.
I'm happy with the situation as it stands (other than wanting to enforce
the exports.txt restriction on more platforms ...)
In that case, shouldn't we add to
On Thu, May 04, 2006 at 09:02:02PM +0200, Thomas Hallgren wrote:
Tom Lane wrote:
Why can PLs not handle pseudo-types?
No one's done the work to figure out which ones are sensible to
support and then add the logic needed to support them.
PL/Java will handle the RECORD type correctly. I'm
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, May 04, 2006 at 03:21:56PM -0400, Tom Lane wrote:
AFAIK, everything that is in exports.txt was put there for a reason.
I'm happy with the situation as it stands (other than wanting to enforce
the exports.txt restriction on more platforms
I have read this thread and I agree with Magnus that we have both new
and experienced users, and we need something simple like SERIAL for new
users.
I agree that having SERIAL be a macro is probably less that useless ---
you can create SERIAL easily, but to remove a table you have to
understand
Bruce Momjian pgman@candle.pha.pa.us writes:
My idea is to create a new SECURITY DEFINER function called
serial_nextval(), and use that for SERIAL defaults.
You haven't thought about this at all. Who will own that function?
Surely we don't want to create a new one for every SERIAL column.
And
Hi William(uniware), Chuck and Hackers,
I have been interested in doing complete PGSQL development in MSVC
for a long time now. With reference to one of Chuck's mails to
-hackers-win32 with the same subject, you said that you were able to
successfully compile PG 8.1 with some minor tweaks.
On 5/4/06, Gurjeet Singh [EMAIL PROTECTED] wrote:
My main grudge is that if we are supporting almost all flovours of
nixens and compilers (close to 34 according to official website), then
why are we leaving Windows platform alone? This will bring in quite a
lot more developers.
Sorry, but
40 matches
Mail list logo
