> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> trigger on "prepare", "commit", "rollback", "savepoint",
> >>> This is a sufficiently frequently asked question that I
> wish someone
> >>> would add an entry to the FAQ about it, or add it to the
> TODO list's
> >>> "Featur
David Fetter wrote:
On Tue, May 20, 2008 at 02:03:17PM -0400, Merlin Moncure wrote:
I wonder if there is any merit to the idea of storing the 'create
view' statement that created the view in an appropriate place.
There are basically two reasons for this:
+1 for DDL in general, including the or
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I wonder if there is any merit to the idea of storing the 'create
> view' statement that created the view in an appropriate place.
No, there isn't.
As counterexamples look at pg_constraint.consrc and pg_attrdef.adsrc,
both of which were mistakes from
On Tue, May 20, 2008 at 02:03:17PM -0400, Merlin Moncure wrote:
> I wonder if there is any merit to the idea of storing the 'create
> view' statement that created the view in an appropriate place.
> There are basically two reasons for this:
+1 for DDL in general, including the original CREATE and
On Tue, May 20, 2008 at 01:20:48PM -0400, Greg Smith wrote:
> On Tue, 20 May 2008, Hannu Krosing wrote:
>
> >Tell others that this trx failed, maybe log a failure ? OTOH, this can
> >be implemented by a daemon that sits on "tail -f logfile | grep
> >ROLLBACK"
>
> In order to follow the log file
I wonder if there is any merit to the idea of storing the 'create
view' statement that created the view in an appropriate place. There
are basically two reasons for this:
*) preserve initial formatting, etc.
Database functions when viewed with \df+ in psql appear nice and clean
as I wrote them.
On Tue, 20 May 2008, Hannu Krosing wrote:
Tell others that this trx failed, maybe log a failure ? OTOH, this can
be implemented by a daemon that sits on "tail -f logfile | grep
ROLLBACK"
In order to follow the log files like that successfully in many
environments, you need to stay in sync as
Hi,
On Mon, 2008-05-19 at 17:10 +0530, cinu wrote:
> This installation is being done on SUSE linux 10
This is not a list for PostgreSQL installation issues, please use
-general or -admin.
...and those packages are *not* for SuSE.
Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consult
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
trigger on "prepare", "commit", "rollback", "savepoint",
This is a sufficiently frequently asked question that I wish someone
would add an entry to the FAQ about it, or add it to the TODO list's
"Features we don't want" section.
OK,
On Tue, 2008-05-20 at 13:36 +0200, Fabien COELHO wrote:
> > or running data modifications through pl/proxy functions where
> > partitioning function always returns two partitions
>
> I don't think that pl/proxy takes care of 2PC semantics in any useful way.
>
> Possibly something like pgpool co
I'm not claiming this is easy, on the contrary, but ISTM that the 2PC
semantics is all what is fundamentaly needed to achieve synchroneous
replication
There are probably easier solutions for achieving this, like using two
connections at client level
Sure, but that means doing the implementat
On Wed, 2008-05-14 at 23:29 +0300, Marko Kreen wrote:
> There are few code beautification ideas on which I'd like to
> get feedback from wider audience:
>
> - Drop CONNECT statement. This was added to make creating
> simple dblink style calls easier, but actually its not
> maintainable compa
On Tue, 2008-05-20 at 12:09 +0200, Fabien COELHO wrote:
> As for replication, I was naively thinking of using BEFORE PREPARE to
> forward a prepare and possibly fail in the master if the slave fails, and
> then an AFTER PREPARE or BEFORE COMMIT/ROLLBACK PREPARE would forward the
> final COMMIT/
On Tue, May 20, 2008 at 06:38:17AM +0100, James Mansion wrote:
> Tom Lane wrote:
> >Another response I've heard is "but I don't want to make
> >inside-the-database changes, I want to propagate the state to someplace
> >external". Of course that's completely broken too, because there is
>
> Some
>
Hi,
Within exec_prepare_plan there are calls to exec_eval_datum to identify the
argtypes of the involved parameters. However exec_eval_datum actually fills
up value, isnull entries in these cases causing unnecessary additional calls
when all we need is the datum type. Such unnecessary evaluation o
Dear Tom,
trigger on "prepare", "commit", "rollback", "savepoint",
I'm sure I've ranted on this several times before, but a quick archive
search doesn't find anything. So, here are a few points to chew on:
I agree that not all of them may make sense, but some may do, and I do not
know whi
Greg Smith wrote
> On Fri, 16 May 2008, Josh Berkus wrote:
>
> > For a hard-core benchmark, I'd try EAStress (SpecJAppserver Lite)
>
> This reminds me...Jignesh had some interesting EAStress results at the
> East conference I was curious to try and replicate more publicly one day.
> Now that
Hello All,
I am trying to install PostgreSQL(postgresql-8.2.4-1PGDG.i686.rpm) on
a 64 bit machine, when I try to install I get the following error
message:
:/home/dump/postgres32bit # rpm -ivh
postgresql-server-8.2.4-1PGDG.i686.rpm
postgresql-8.2.4-1PGDG.i686.rpm postgresql-li
Hi, Thanks for the reply...When you are saying that I need to install 32 bit version of Libraries, are you referring to the libraries that are specified in the error message, I infact searched for the libraries and got it installed but some of the libraries are not available for SUSE Linux, if you
On Mon, 2008-05-19 at 21:53 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> trigger on "prepare", "commit", "rollback", "savepoint",
> >>
> >> This is a sufficiently frequently asked question that I wish someone
> >> would add an entry to the FAQ about it, or add it to th
20 matches
Mail list logo
