On Friday 14 March 2008 11:36, Marko Kreen wrote:
On 3/14/08, Erik Jones [EMAIL PROTECTED] wrote:
On Mar 14, 2008, at 7:17 AM, Marko Kreen wrote:
To put it to core Postgres, it needs to be conceptually sane
first, without needing ugly workarounds to avoid it bringing
whole db down.
On 3/14/08, Dawid Kuroczko [EMAIL PROTECTED] wrote:
On Thu, Mar 13, 2008 at 2:18 PM, Marko Kreen [EMAIL PROTECTED] wrote:
On 3/13/08, Dawid Kuroczko [EMAIL PROTECTED] wrote:
An application which uses tsearch2 ('SELECT set_curdict() /
set_curcfg()' being
called upon session
On Mar 14, 2008, at 7:17 AM, Marko Kreen wrote:
To put it to core Postgres, it needs to be conceptually sane
first, without needing ugly workarounds to avoid it bringing
whole db down.
I can see ATM only few ways:
- Applies only to non-superusers.
- Error from CONNECT trigger does not
On Mar 14, 2008, at 10:36 AM, Marko Kreen wrote:
Another option:
Does not fire at all in single-user mode. This would be covered by
Applies to non-superusers if that were there but, by itself, the
triggers would still fire for normal superuser connections.
Seems bit too hard - you may
On 3/14/08, Erik Jones [EMAIL PROTECTED] wrote:
On Mar 14, 2008, at 7:17 AM, Marko Kreen wrote:
To put it to core Postgres, it needs to be conceptually sane
first, without needing ugly workarounds to avoid it bringing
whole db down.
I can see ATM only few ways:
- Applies
On Mar 13, 2008, at 2:00 AM, Berend Tober wrote:
Alban Hertroys wrote:
On Mar 11, 2008, at 10:28 PM, Tom Lane wrote:
An ON CONNECT trigger enforced by the database seems a bit scary
to me.
If it's broken, how you gonna get into the DB to fix it?
regards, tom lane
If creating
On Tue, Mar 11, 2008 at 10:28 PM, Tom Lane [EMAIL PROTECTED] wrote:
Kynn Jones [EMAIL PROTECTED] writes:
If one can set up this insert operation so that it happens automatically
whenever a new connection is made, I'd like to learn how it's done.
For manual psql sessions, you can put some
Tom Lane wrote:
For manual psql sessions, you can put some setup commands in
~/.psqlrc.
In any other context I'm afraid you're stuck with modifying your
client
application code.
An ON CONNECT trigger enforced by the database seems a bit scary to
me.
If it's broken, how you gonna
On 3/13/08, Dawid Kuroczko [EMAIL PROTECTED] wrote:
On Tue, Mar 11, 2008 at 10:28 PM, Tom Lane [EMAIL PROTECTED] wrote:
Kynn Jones [EMAIL PROTECTED] writes:
If one can set up this insert operation so that it happens automatically
whenever a new connection is made, I'd like to learn
On Thu, Mar 13, 2008 at 2:18 PM, Marko Kreen [EMAIL PROTECTED] wrote:
On 3/13/08, Dawid Kuroczko [EMAIL PROTECTED] wrote:
An application which uses tsearch2 ('SELECT set_curdict() / set_curcfg()'
being
called upon session start). That is fine and that works.
Now, using statement
On Tue, Mar 11, 2008 at 5:28 PM, Tom Lane [EMAIL PROTECTED] wrote:
Kynn Jones [EMAIL PROTECTED] writes:
If one can set up this insert operation so that it happens automatically
whenever a new connection is made, I'd like to learn how it's done.
For manual psql sessions, you can put some
Kynn Jones wrote:
On Tue, Mar 11, 2008 at 5:28 PM, Tom Lane [EMAIL PROTECTED] wrote:
Kynn Jones [EMAIL PROTECTED] writes:
If one can set up this insert operation so that it happens automatically
whenever a new connection is made, I'd like to learn how it's done.
For manual psql sessions, you
On Wed, Mar 12, 2008 at 07:52:29AM -0400, Kynn Jones wrote:
An ON CONNECT trigger enforced by the database seems a bit scary to me.
If it's broken, how you gonna get into the DB to fix it?
A psql --skip-on-connect-trigger, only available to, say,
superusers ? Or a database flag (like the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hi! I want to set up a trigger (somehow) that, whenever someone connects
database my_db, will fire and thereby run a stored PLPERL procedure
perl_setup() in the new connection's environment. (BTW, this procedure adds
useful definitions,
On Tue, Mar 11, 2008 at 4:51 PM, Andrej Ricnik-Bay [EMAIL PROTECTED]
wrote:
On 12/03/2008, Kynn Jones [EMAIL PROTECTED] wrote:
Of course I may not have quite
understood how that this procedure adds useful definitions,
mostly subs, to Perl's main package. This needs to be done
for each
On Mar 11, 2008, at 10:28 PM, Tom Lane wrote:
An ON CONNECT trigger enforced by the database seems a bit scary to
me.
If it's broken, how you gonna get into the DB to fix it?
regards, tom lane
If creating the trigger wouldn't be possible from within the database
Alban Hertroys wrote:
On Mar 11, 2008, at 10:28 PM, Tom Lane wrote:
An ON CONNECT trigger enforced by the database seems a bit scary to me.
If it's broken, how you gonna get into the DB to fix it?
regards, tom lane
If creating the trigger wouldn't be possible from within the
On Mon, Mar 10, 2008 at 7:47 PM, Alban Hertroys
[EMAIL PROTECTED] wrote:
You can't define triggers on system tables.
Oh, well... :-/ Thanks for the reality check!
If not, is there some other way to set up a trigger that
Oops. I guess a cut-and-paste error in my original message must
On 12/03/2008, Kynn Jones [EMAIL PROTECTED] wrote:
If one can set up this insert operation so that it happens automatically
whenever a new connection is made, I'd like to learn how it's done. But if
not, then I don't see how performing the insert manually every time one
connects would be any
Kynn Jones [EMAIL PROTECTED] writes:
If one can set up this insert operation so that it happens automatically
whenever a new connection is made, I'd like to learn how it's done.
For manual psql sessions, you can put some setup commands in ~/.psqlrc.
In any other context I'm afraid you're stuck
Hi! I want to set up a trigger (somehow) that, whenever someone connects
database my_db, will fire and thereby run a stored PLPERL procedure
perl_setup() in the new connection's environment. (BTW, this procedure adds
useful definitions, mostly subs, to Perl's main package. This needs to be
done
On Mar 10, 2008, at 9:07 PM, Kynn Jones wrote:
So I tried to find some system table that would get modified
whenever a new connection was made, but I was unsuccessful. The
closest I found was the VIEW pg_activity, and the crucial
information I need from this view comes from procedures
22 matches
Mail list logo
