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?
--
greg
---(end of
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.
mainLOOP
...
...
END LOOPmain;
Regards
Pavel Stehule
diff -c -r --new-file pgsql/doc/src/sgml/plpgsql.sgml
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,
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
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 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
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. Because
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
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)
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 any
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.
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 works fine in a
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
would
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 that's
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 following:
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
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.
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 for
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 the flags is not
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
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 any
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
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
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
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 beingimplemented inMySQL 5.0. Note
that I'm NOT a big fan of adding Oracle compatibility to PL/pgSQL, but,
Bruce Momjian pgman@candle.pha.pa.us 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
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 for quite
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.
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 appears to
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 else is
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 form
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 PL/pgSQL
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.
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
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, would
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
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
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 of
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 that
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:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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
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 to be
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 enough alone?
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|
* 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 pretty
Bruce Momjian pgman@candle.pha.pa.us 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
* 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 anybody is
Larry Rosenman ler@lerctr.org 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
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 -o
Bruce Momjian pgman@candle.pha.pa.us 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.
Tom Lane wrote:
Larry Rosenman ler@lerctr.org 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
I have updated the open items based on recent discussions:
---
PostgreSQL 8.1 Open Items
=
Current version at
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
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-tree,
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
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 integrating
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
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 might
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 ~
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 really. It
61 matches
Mail list logo
