Jim Nasby wrote:
Following that logic we should remove all data types that aren't
specified in ANSI.
Sure, if we were to arrive at some acceptable implementation of official
modules, that would make sense in some cases.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Thu, Jan 25, 2007 at 08:56:27PM +0100, Magnus Hagander wrote:
Bruce Momjian wrote:
I need an updated version of this to apply. The suggested changes are
too extensive.
I'll try to do this tomorrow. If I get it right, the changes needed are:
NULL instead of cast of function ptr, per
Folks,
As commented by Peter, I have done some re-styling.
Some additional tests and format checking have been added to this patch.
Put your file at the end of the OBJS variable (or in some sort of
sensible order).
Done.
Put your file at the end of the tests (or in some sort of sensible
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Peter Eisentraut replied:
The harm here is that under undefined circumstances a dump file
will not be a proper and robust representation of the original
database, which would add significant confusion and potential for error.
What
1) mvcc.sgml.patch
Update comments about installation of DocBook on FreeBSD. DocBook v4.2 is
present in ports now.
2) docguide.sgml.patch
Table of compatibility of table-lock modes. IMHO, it's useful, clear for
understanding. Text view of the table is:
| AS | RS | RE | SUE |
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Peter Eisentraut replied:
The harm here is that under undefined circumstances a dump file
will not be a proper and robust representation of the original
database, which would add significant confusion and potential for error.
What undefined
On Fri, 2007-01-26 at 12:53 +0100, Magnus Hagander wrote:
Ok, here's an updated patch per this.
Applied -- thanks for the patch.
-Neil
---(end of broadcast)---
TIP 6: explain analyze is your friend
Hello
this patch contains ansi sql scrollable cursors's support for plpgsql. Add
three function to SPI and plpgsql scrollable cursor sup. is first test app
of this functionality.
Regards
Pavel Stehule
_
Citite se osamele?
On Thu, 25 Jan 2007, Jeremy Drake wrote:
On Thu, 25 Jan 2007, Jeremy Drake wrote:
I think that an ALTER LANGUAGE OWNER TO is the proper response to these
things, and unless I hear otherwise I will attempt to add this to my
patch.
Here is the patch which adds this. It also allows ALTER
Alvaro Herrera [EMAIL PROTECTED] writes:
The launcher is a dummy process; it never connects to any database.
... Eventually this will need to
be changed so that the launcher tells the worker exactly what table to
work on.
I detect a certain lack of clarity of thinking here. Either the
Attached is a patch which should marginally improve the ctid chain followin
code path when current and the next tuple in the chain are in the same
block.
In the current code, we unconditionally drop pin of the current block
without
checking whether the next tuple is the same block or not. ISTM
Jeremy Drake [EMAIL PROTECTED] writes:
The only difference from this is, that when superuser is required, the
owner of the language is not the superuser who created it, but
BOOTSTRAP_SUPERUSERID. This is because my interpretation was that the
same behavior as currently took precedence. The
On Sat, 27 Jan 2007, Tom Lane wrote:
I'd go with GetUserId() in the cases where you're not explicitly
assigning ownership to the datdba role. AFAIR the assumption that
languages are owned by BOOTSTRAP_SUPERUSERID was just a kluge to use in
some bits of code that had to have a notion of a
13 matches
Mail list logo
