Zdenek,
On Wed, May 24, 2006 at 04:27:01PM +0200, Zdenek Kotala wrote:
General config structure is extend with default_val attribute to keep
really default value. (There is small conflict - for string boot_val
has same meaning).
During reconfiguration all values which has reset source equal
Joachim,
thanks for your comments. I am working on them.
Zdenek
Joachim Wieland wrote:
Zdenek,
Three points after a quick test:
- please compile with --enable-cassert, there are wrong assertions in your
code (you might just have to move some lines, there is an Assert() and an
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Adam Sjøgren wrote:
Enclosed is a tiny patch for plperl that puts the schema-name of the
current table in $_TD, so triggers can access tables using
schemaname.tablename, for instance like so:
This seems like a good
The attached patch enables psql to copy binary data in and out.
Regards,
Andreas
Index: src/bin/psql/copy.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/copy.c,v
retrieving revision 1.60
diff -u -r1.60 copy.c
---
Andrew Dunstan [EMAIL PROTECTED] writes:
plpython and pltcl don't have relname, while only pltcl has relatts. Is
relatts useful? should we provide it everywhere?
Hm. It is not particularly useful in plpgsql at the moment, because of
the lack of any way to reference columns dynamically. So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
plpython and pltcl don't have relname, while only pltcl has relatts. Is
relatts useful? should we provide it everywhere?
Might as well - does no harm to add it in.
I propose to add relname to plpython and pltcl, and relschema to all
(mutatis
This patch cleans up the use of E'' strings in 8.2. 8.2 is the first
release where standard_conforming_strings can be 'on', and when 'on',
escape_string_warning is disabled.
In 8.1, the behavior was to use E'' strings for any case where
backslashes exist. For 8.2, per suggestion from Tom, we
An article at WebProNews quoted from the PG docs as to the merits of
stored procedures. I have added a bit more material on their merits,
as well as making a few changes to improve the introductions to
PL/Perl and PL/Tcl.
Index: plperl.sgml
On Wed, 24 May 2006 10:12:17 -0400, Andrew wrote:
Patches should be made against the HEAD branch in CVS, not against a
distro source.
Ok; I'll do that. (The patch did apply cleanly to CVS, though, but
anyway).
On Wed, 24 May 2006 15:41:07 -0400, Tom wrote:
Andrew Dunstan [EMAIL PROTECTED]
Alvaro Herrera [EMAIL PROTECTED] writes:
CREATE TABLE foo (a int);
for some unknown reason, an inval message involving relation foo seems
to be emitted.
heap_unfreeze(pg_class)
CommandCounterIncrement()
heap_unfreeze(pg_attribute)
CommandCounterIncrement()
... insert the pg_attribute
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
CREATE TABLE foo (a int);
for some unknown reason, an inval message involving relation foo seems
to be emitted.
heap_unfreeze(pg_class)
CommandCounterIncrement()
heap_unfreeze(pg_attribute)
CommandCounterIncrement()
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Where did all these CommandCounterIncrement calls come from?
I added them in heap_unfreeze precisely because I want the relation to
be frozen exactly once, and this doesn't seem to happen if I don't CCI
there -- I was seeing multiple
Adam Sjøgren said:
I haven't looked at the other languages as I do not use them; let me
know if I should take a stab at providing patches for them as well.
I will take it from here. Thanks.
andrew
---(end of broadcast)---
TIP 3: Have you
I wrote:
Well, that needs rethinking. The unfreeze has to be a non-transactional
update (if our transaction rolls back, the unfreeze still has to
stick, because we may have put dead tuples into the rel).
Actually, this seems even messier than I thought. Consider a
transaction that does
Tom Lane wrote:
I wrote:
Well, that needs rethinking. The unfreeze has to be a non-transactional
update (if our transaction rolls back, the unfreeze still has to
stick, because we may have put dead tuples into the rel).
Actually, this seems even messier than I thought. Consider a
Alvaro Herrera [EMAIL PROTECTED] writes:
Well, if a transaction modifies a table in some way, even without
changing the data, should generate an unfreeze event, because it will
need to lock the table; for example AlterTable locks the affected
relation with AccessExclusiveLock. It's important
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Well, if a transaction modifies a table in some way, even without
changing the data, should generate an unfreeze event, because it will
need to lock the table; for example AlterTable locks the affected
relation with
17 matches
Mail list logo
