Tom Lane <[EMAIL PROTECTED]> writes:
> "John Hansen" <[EMAIL PROTECTED]> writes:
>
> > Simplicity!
> > Implementing rtree operators and support functions is FAR simpler than
> > implementing the GiST equivalents.
>
> Mmm ... not really. It does seem that we could offer some sort of
> generic se
"John Hansen" <[EMAIL PROTECTED]> writes:
> Tom Lane Wrote:
>> ... but rtree has always
>> been marginal, and it's very hard to see where it can win over gist.
> Simplicity!
> Implementing rtree operators and support functions is FAR simpler than
> implementing the GiST equivalents.
Mmm ... not
Tom Lane Wrote:
> ... but rtree has always
> been marginal, and it's very hard to see where it can win over gist.
Simplicity!
Implementing rtree operators and support functions is FAR simpler than
implementing the GiST equivalents.
For example, suppose all you want to implement is the ~ operat
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Will you just remove rtree and make rtree indexes use rtree_gist instead?
That is in the back of my mind for 8.2 or so; I thought it'd be a bit
premature to propose it for 8.1, though.
The real bottom line here is that any devel effort we migh
Also, isn't rtree still substantially faster than gist?
Not according to contrib/rtree_gist/bench/, though I admit I have not
bothered to reproduce the experiment.
Will you just remove rtree and make rtree indexes use rtree_gist instead?
Chris
---(end of broadcast)--
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> * With the recent WAL-ization and hoped-for concurrency fixes, GiST
>> is definitely superior to R-tree for practical use. I don't see the
>> percentage in continuing to maintain the R-tree code indefinitely.
>> By in
Bruce Momjian wrote:
Is this a TODO item?
Probably. I posted some questions regarding whether or not to break
backward compatiblity, and received no replies. In the meanwhile, I've
been doing a major system integration in Korea for the last 2 weeks, and
won't get back to home, or to anythin
Tom Lane <[EMAIL PROTECTED]> writes:
> * With the recent WAL-ization and hoped-for concurrency fixes, GiST
> is definitely superior to R-tree for practical use. I don't see the
> percentage in continuing to maintain the R-tree code indefinitely.
> By integrating the opclasses needed to replace R-
Bruce Momjian wrote:
KRB4 removal patch (Magnus)
This is done.
There are also two PL/PgSQL patches from Pavel that need to be reviewed
and applied:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01202.php
http://archives.postgresql.org/pgsql-patches/2005-06/msg00475.php
I'll revie
I have updated the open items based on recent discussions:
---
PostgreSQL 8.1 Open Items
=
Current version at http://candle.pha.pa.us/cgi
Tom Lane wrote:
> "Larry Rosenman" writes:
>> Did the build system change between 8.0 and HEAD?
>
> I don't think so --- certainly there are no changes in
> template/unixware or makefiles/Makefile.unixware, which is where
> you'd expect to find any platform-specific stuff. The ar command
> being
Bruce Momjian writes:
> I will be in Maryland from Monday through Thursday doing training. I
> will have internet access so in the evenings I will be online to read
> email and apply patches.
> I realize this isn't an ideal time to be away but I didn't have much of
> a choice.
I think that actu
Larry Rosenman wrote:
> Trying to set up my 7.1.4 box as a buildfarm member, and can't get
> through A build. The latest failure (after removing --with-perl) is:
>
> $ tail -20 ../../../lastrun-logs/make-contrib.log
> cc -O -Kinline -g -K PIC -I. -I../../src/include
> -I/usr/local/include -c -
"Larry Rosenman" writes:
> Did the build system change between 8.0 and HEAD?
I don't think so --- certainly there are no changes in template/unixware
or makefiles/Makefile.unixware, which is where you'd expect to find any
platform-specific stuff. The ar command being complained of looks
pretty s
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Roles? (Stephen Frost)
>
> > Additionally, my shared dependencies patch :-) I'm not sure if I'll be
> > able to do both autovacuum and shared dependencies before freeze, but
> > I'll try. I'm not sure if anyb
Bruce Momjian writes:
> Can someone come up with a better name than total_relation_size(),
> because we already have relation_size()? The problem is that in the
> first case, relation means the relation/indexes/toast, and in the second
> it is just the heap. Should we call relation_size() pg_hea
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> Additionally, my shared dependencies patch :-) I'm not sure if I'll be
> able to do both autovacuum and shared dependencies before freeze, but
> I'll try. I'm not sure if anybody is working on roles though; if I have
> to do the three of them I'm pret
I will be in Maryland from Monday through Thursday doing training. I
will have internet access so in the evenings I will be online to read
email and apply patches.
I realize this isn't an ideal time to be away but I didn't have much of
a choice.
--
Bruce Momjian| http
Robert Treat wrote:
> On Sunday 26 June 2005 21:23, Tom Lane wrote:
> > I just noticed that these two modules define operator @ as "contains"
> > and operator ~ as "contained by", which is opposite to the meanings used
> > by every other datatype.
> >
> > Is it better to fix this or leave well enou
On Sunday 26 June 2005 21:23, Tom Lane wrote:
> I just noticed that these two modules define operator @ as "contains"
> and operator ~ as "contained by", which is opposite to the meanings used
> by every other datatype.
>
> Is it better to fix this or leave well enough alone?
>
ISTM it will have t
On Sun, 26 Jun 2005, Tom Lane wrote:
I just noticed that these two modules define operator @ as "contains"
and operator ~ as "contained by", which is opposite to the meanings used
by every other datatype.
Is it better to fix this or leave well enough alone?
I'd say for consistencies sake, it
Tom Lane wrote:
> Bruce Momjian writes:
> > Here are the open items. Feature freeze is Friday, July 1.
>
> This is missing the point that pg_dump output is not forward compatible
> with the planned escape string changeover.
>
> We had talked about tweaking ruleutils.c, as well as pg_dump itself
Trying to set up my 7.1.4 box as a buildfarm member, and can't get through
A build. The latest failure (after removing --with-perl) is:
$ tail -20 ../../../lastrun-logs/make-contrib.log
cc -O -Kinline -g -K PIC -I. -I../../src/include -I/usr/local/include -c
-o seg.o seg.c
UX:cc: WARNING: debu
Michael Paesold wrote:
> > relation_size_components() depends on total_relation_size() (which I
> > have to agree could be useful). I think relation_size_components() is
> > unecessary though - it looks like it was designed to show a summary
> > rather than as a view to be used by other clients (if
I just noticed that these two modules define operator @ as "contains"
and operator ~ as "contained by", which is opposite to the meanings used
by every other datatype.
Is it better to fix this or leave well enough alone?
regards, tom lane
---(end o
On Sat, 2005-06-25 at 23:24 -0400, Bruce Momjian wrote:
> Here are the open items. Feature freeze is Friday, July 1.
>
> ---
>
>
>PostgreSQL 8.1 Open Items
>==
Alvaro Herrera wrote:
On Sun, Jun 26, 2005 at 04:44:13PM -0400, Andrew Dunstan wrote:
Is the intention here to make PSM a first class language (i.e. handled
by the main dbengine scanner/parser) of just another PL? If the latter
it seems far less worth doing. Doing this as a first class l
On Sun, Jun 26, 2005 at 04:44:13PM -0400, Andrew Dunstan wrote:
> Is the intention here to make PSM a first class language (i.e. handled
> by the main dbengine scanner/parser) of just another PL? If the latter
> it seems far less worth doing. Doing this as a first class language,
> however, wou
Is the intention here to make PSM a first class language (i.e. handled
by the main dbengine scanner/parser) of just another PL? If the latter
it seems far less worth doing. Doing this as a first class language,
however, would be great, just great.
As for pgfoundry, I think it's fair to say (
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Yeah. I think we'd need to add "where langlcallfoid != 0" so we don't
pick up the internal/C/sql handlers. However, on closer inspection it
appears that doind all this in pg_dump would be lots more invasive than
I first thought.
On Sun, 26 Jun 2005, Tom Lane wrote:
> "Denis Lussier" <[EMAIL PROTECTED]> writes:
> > For various technical and backward compatibility reasons, I don't think
> > SQL/PSM should be a replacement for PL/pgSQL. Although I do think it
> > should heavily leverage the solid foundation afforded by the
On Mon, 27 Jun 2005, Neil Conway wrote:
> Peter Eisentraut wrote:
> > It is required by the SQL standard.
>
> No, it isn't -- PL/PgSQL is not defined by the SQL standard. I guess
> you're referring to SQL/PSM, but that has only a passing resemblance to
> PL/PgSQL. Implementing SQL/PSM in some f
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Yeah. I think we'd need to add "where langlcallfoid != 0" so we don't
> pick up the internal/C/sql handlers. However, on closer inspection it
> appears that doind all this in pg_dump would be lots more invasive than
> I first thought.
Why --- what el
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> With that exception, we now have only one machine marked active that has
> consistently failed on HEAD or REL8_0_STABLE: osprey (NetBSD 2.0 gcc
> 3.3.3 m68k)
> I have asked its owner to look into what the problems might be.
The failure on HEAD appear
Tom Lane wrote:
regression=# explain analyze select * from pg_proc WHERE NOT proisagg AND (pronamespace != (select oid from pg_namespace where nspname = 'pg_catalog')
regression(# OR oid in (select lanplcallfoid from pg_language) OR oid in (select lanvalidator from pg_language));
Yeah.
"Denis Lussier" <[EMAIL PROTECTED]> writes:
> For various technical and backward compatibility reasons, I don't think
> SQL/PSM should be a replacement for PL/pgSQL. Although I do think it
> should heavily leverage the solid foundation afforded by the PL/pgSQL
> code base.
"Solid"? I've wanted f
Bruce Momjian writes:
> Here are the open items. Feature freeze is Friday, July 1.
This is missing the point that pg_dump output is not forward compatible
with the planned escape string changeover.
We had talked about tweaking ruleutils.c, as well as pg_dump itself,
to use E'...' syntax if the
Hi All,
My company (EnterpriseDB) is very interested
in helping to make ANSI-ISO SQL Stored Procedures part of standard BSD
Postgres. The SQL/PSM standard is currently
used in DB2 and is being implemented in MySQL 5.0. Note
that I'm NOT a big fan of adding Oracle compatibility to PL/pgSQL,
Would it be possible to rollback from WAL? My thought is this:
CREATE DATABASE is logged in WAL
If a replay of that CREATE DATABASE is performed, the template database
used is copied
Any modifications to the template database that occured after the CREATE
DATABASE are rolled back in the new databa
On Sun, 26 Jun 2005, Andrew Dunstan wrote:
The buildfarm member penguin (Debian, ARM) has been building the HEAD branch
for the most part happily since late January, but keeps failing on the
REL8_0_STABLE branch on tsearch2. It appears that some changes made around
24-27 January fixed it for
Tom Lane wrote:
However, we cannot
backpatch the change without forcing initdb (or at least reindex of
tsearch2 indexes), even on architectures that are not currently broken.
So I'm afraid penguin is out of luck --- the 8.0 branch has to stay
the way it is.
With that exception, we now
Neil Conway wrote:
> No, it isn't -- PL/PgSQL is not defined by the SQL standard. I guess
> you're referring to SQL/PSM, but that has only a passing resemblance
> to PL/PgSQL. Implementing SQL/PSM in some form would definitely be
> worth doing (especially now that MySQL have), but I haven't seen an
Peter Eisentraut wrote:
It is required by the SQL standard.
No, it isn't -- PL/PgSQL is not defined by the SQL standard. I guess
you're referring to SQL/PSM, but that has only a passing resemblance to
PL/PgSQL. Implementing SQL/PSM in some form would definitely be worth
doing (especially now
Bruce Momjian wrote:
> Atsushi Ogawa wrote:
> > I propose the following specification:
> >
> > regexp_replace(source text, pattern text, replacement text, [flags
text])
> > returns text
> >
> > The flags can use the following values:
> > g: global (replace all)
> > i: ignore case
> >
> > When th
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The buildfarm member penguin (Debian, ARM) has been building the HEAD
> branch for the most part happily since late January, but keeps failing
> on the REL8_0_STABLE branch on tsearch2. It appears that some changes
> made around 24-27 January fixed it
I've mentioned this a couple times now, but here is an official
proposal:
I would like to move the contrib/rtree_gist functionality into the core
system before feature freeze. There are a couple arguments in favor:
* It's way past time GiST indexes got some regression testing in the
core build.
The buildfarm member penguin (Debian, ARM) has been building the HEAD
branch for the most part happily since late January, but keeps failing
on the REL8_0_STABLE branch on tsearch2. It appears that some changes
made around 24-27 January fixed it for this architecture/OS. Looking in
the commit
I wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> Notice also that contrib/seg and contrib/cube have their own, and
>> incompatible, idea of what the semantics of &< and &> should be.
> Um. Not sure what to do about these ... any opinions?
Having looked at this, I propose the followin
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Jan Wieck wrote:
>> The other annoyance this redesign would fix is the createdb failures
>> because the template DB is in use.
> This one should be largely fixed by provision of another default
> connection target, which is in the pipeline.
Yeah, but
Robert Treat <[EMAIL PROTECTED]> writes:
> On Saturday 25 June 2005 23:24, Bruce Momjian wrote:
>> Here are the open items. Feature freeze is Friday, July 1.
> Where does the rest of the "contrib roundup" fit into this picture?
I think that moving rtree_gist, reindexdb, and/or userlock into core
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> (b) force a checkpoint
>> immediately after any CREATE DATABASE, so that we never have to replay
>> one except in a PITR situation
> So wouldn't this mean that any CREATE DATABASE won't work properly in PITR?
It work
Jan Wieck wrote:
One way of redesigning CREATE DATABASE would be to build the new
database directory from scratch using bki files. Doing so would lose
the current template mechanism, but that can easily be redesigned into
a utility that creates a bki file set from any existing database. Th
Jan Wieck <[EMAIL PROTECTED]> writes:
> One way of redesigning CREATE DATABASE would be to build the new
> database directory from scratch using bki files. Doing so would lose the
> current template mechanism, but that can easily be redesigned into a
> utility that creates a bki file set from an
On 6/25/2005 6:58 PM, Tom Lane wrote:
I wrote:
It seems our choices are (a) somehow fix things so CREATE DATABASE
replay doesn't have to zap the whole directory, (b) force a checkpoint
immediately after any CREATE DATABASE, so that we never have to replay
one except in a PITR situation, or (c) a
Bruce Momjian wrote:
convert plperl arrays to pg arrays? (Andrew Dunstan)
Won't be done :-( . Too many wrinkles. Covered by recently added TODO item.
plperl validator function? (Andrew Dunstan)
Done and merged.
Also, I am going to try to get done putting language handlers in
pg_c
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
> (b) force a checkpoint
> immediately after any CREATE DATABASE, so that we never have to replay
> one except in a PITR situation
So wouldn't this mean that any CREATE DATABASE won't work properly in
PITR?
As I understand it: no. Bec
On L, 2005-06-25 at 23:24 -0400, Bruce Momjian wrote:
> Here are the open items. Feature freeze is Friday, July 1.
I'm still hoping to get my concurrent vacuum patch in shape before
feature freeze
--
Hannu Krosing <[EMAIL PROTECTED]>
---(end of broadcast)--
Dave Page wrote:
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: 24 June 2005 21:12
> To: Bruce Momjian
> Cc: Dave Page; PostgreSQL-development
> Subject: Re: [HACKERS] DBSize backend integration
>
> Bruce Momjian wrote:
>
> >
> >So drop total_relation_size(
On Saturday 25 June 2005 23:24, Bruce Momjian wrote:
> Here are the open items. Feature freeze is Friday, July 1.
>
> ---
>
>
>PostgreSQL 8.1 Open Items
>
On Sat, 25 Jun 2005, Bruce Momjian wrote:
Here are the open items. Feature freeze is Friday, July 1.
GIST concurrency fixes? (Oleg)
This should be
GIST concurrency support (Teodor, Oleg)
also, after moving rtree_gist into core we should add
regression tests for GIST.
Regards,
Hello
this patch allows optional using label with END and END LOOP. Ending label
has only informational value, but can enhance readability large block and
enhance likeness with Oracle.
<>LOOP
...
...
END LOOP<>;
Regards
Pavel Stehule
diff -c -r --new-file pgsql/doc/src/sgml/plpgsql.sgml
pgs
61 matches
Mail list logo
