Bruce Momjian wrote:
I am not sure what to do with this patch. It is missing dump
capability, there is no clause to disable all triggers on a table, and
it uses a table owner check when a super user check is required (because
of referential integrity).
From a user's view, a trigger
On Tue, Jul 05, 2005 at 10:20:17AM +1000, Neil Conway wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
That is not the latest version of Marko's patch.
Bruce got v3, thats indeed the latest.
Also, http://momjian.postgresql.org/cgi-bin/pgpatches
Several libpqxx users have been reporting odd problems with certain error
messages generated by libpq. One of them was the inclusion of garbage
data.
As it turns out, src/interfaces/libpq/fe-misc.c contains several instances
of this construct:
printfPQExpBuffer(conn-ErrorMessage,
Here's another one similar to what I described in my previous message. In
libpq's pqsecure_read(), if SSL_read() returns -1 and sets an error of
SSL_ERROR_SYSCALL, errno may be polluted by libpq_gettext() before a
human-readable string is derived from it. Also, pqReadData() will see the
wrong
On Mon, Jul 04, 2005 at 03:04:51PM -0400, Bruce Momjian wrote:
Patch applied. Thanks.
Gerrit van Dyk wrote:
This patch allows the PL/Python module to do (SRF) functions.
Does this patch work? The test_setof() function in sql/plpython_setof.sql
gives me the following:
SELECT * FROM
This patch updates the DDL for contrib/pgcrypto to create all
functions as STRICT, and all functions except gen_salt() as IMMUTABLE.
gen_salt() is VOLATILE.
Although the functions are now STRICT, I left their PG_ARGISNULL()
checks in place as a protective measure for users who install the
new
[EMAIL PROTECTED] writes:
Another approach would have been to make libpq_gettext() preserve errno.
That seems like a far easier, cleaner, and more robust fix than this.
Moreover I don't believe that this approach works either, as the result
of strerror() is not guaranteed still usable after
[EMAIL PROTECTED] writes:
Here's another one similar to what I described in my previous message.
More or less proves my point, no? Even if you manage to fix every
occurence of this issue now, it'll keep popping up as people change
the code. This approach is just not maintainable.
On Tue, Jul 05, 2005 at 04:23:42PM +0200, Gerrit van Dyk wrote:
Ok, I just looked at the code again and the results I am getting, is
what you expect.
2 rows every time returning 1 and 2.
What version of postgres are you running, I am running 8.0.3
I'm running HEAD (8.1devel), which is
Michael Fuhr [EMAIL PROTECTED] writes:
I'm running HEAD (8.1devel), which is where the patch was committed.
Could somebody else test HEAD and see what they get?
Same as you --- ie, this patch is utterly broken.
I don't see the setof functionality in the regression tests,
presumably because
[EMAIL PROTECTED] writes:
Attached is a patch (by Gavin Sherry, fixed up to apply to 8.1 by me) that
implements INSERT ... RETURNING functionality.
It does work for the common case of RETURNING the value of a serial/sequence
column, but gets confused when returning results out-of-order
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
The current implementation of XID wraparound requires that the vacuum
command be run against the entire database, you can not run it on a per
table basis and have it work. At least that is my understanding,
No, you're
Matthew T. O'Connor matthew@zeut.net writes:
Tom Lane wrote:
No, you're wrong. VACUUMing of individual tables is perfectly good
enough as far as XID wrap protection goes, it's just that we chose to
track whether it had been done at the database level. If we tracked it
in, say, a new
Michael Fuhr [EMAIL PROTECTED] writes:
This patch allows the PL/Python module to do (SRF) functions.
Does this patch work?
Aside from minor problems like being broken and undocumented, there is a
more serious question here: is this even the functionality we want?
The proposed test case is:
On Tue, Jul 05, 2005 at 01:00:50PM -0400, Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
Tom Lane wrote:
No, you're wrong. VACUUMing of individual tables is perfectly good
enough as far as XID wrap protection goes, it's just that we chose to
track whether it had been done
On Tue, Jul 05, 2005 at 01:14:25PM -0400, Tom Lane wrote:
Aside from minor problems like being broken and undocumented, there is a
more serious question here: is this even the functionality we want?
I'd rather see something akin to PL/pgSQL's RETURN NEXT or PL/Perl's
return_next.
--
Michael
OK, patch backed out, new and regression file removed.
---
Andrew Dunstan wrote:
Michael Fuhr wrote:
On Tue, Jul 05, 2005 at 01:14:25PM -0400, Tom Lane wrote:
Aside from minor problems like being broken and
TODO item?
---
Alvaro Herrera wrote:
On Tue, Jul 05, 2005 at 01:00:50PM -0400, Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
Tom Lane wrote:
No, you're wrong. VACUUMing of individual tables is
I think so. Something like: Improve autovacuum xid wraparound detection
by moving to a pertable solution rather than per database.
Matt
Bruce Momjian wrote:
TODO item?
---(end of broadcast)---
TIP 2: you can get off all lists at once
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, Jul 05, 2005 at 02:47:15PM -0400, Tom Lane wrote:
Although I don't have any particular objection to the OWNER/NORMAL
distinction, your explanation doesn't seem to make sense. Don't you
have to poke the Acl anyway, if it's non-null? Else the
Another question about this: why bother with dependencies on
tablespaces? That seems to me to be isomorphic with dependencies on
databases --- we don't need those either, because in both cases we
count on the filesystem to provide ground truth about which objects
live inside a
Bruce Momjian wrote:
This also adds a full_page_writes GUC to turn off page writes to WAL.
Some people might not want full_page_writes.
Fsync linkage removed, patch attached and applied.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
Bruce Momjian pgman@candle.pha.pa.us writes:
If we go pg_table_size() and pg_relation_size(), which is object-only
and which is heap + index + toast? I think ideally we want
pg_relation_size to be the combined one, but then we have pg_table_size
that works on indexes and toast too, and that
Bruce Momjian wrote:
I am not sure what to do with this patch. It is missing dump
capability, there is no clause to disable all triggers on a table, and
it uses a table owner check when a super user check is required (because
of referential integrity).
Satoshi, are you still working on it?
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
I could live with that. Or pg_total_relation_size.
The problem with total, to me, is that it already is the total size of
the heap/index/toast. Complete has the idea of adding additional
pieces, which I think fits best.
[ shrug
Greg Sabino Mullane wrote:
http://archives.postgresql.org/pgsql-patches/2005-05/msg00197.php
Applied.
---
Attached is a patch that enhances the \h capability in psql. I often
find myself typing a command and then wanting
Satoshi Nagayasu wrote:
Bruce Momjian wrote:
I am not sure what to do with this patch. It is missing dump
capability, there is no clause to disable all triggers on a table, and
it uses a table owner check when a super user check is required (because
of referential integrity).
27 matches
Mail list logo
