Hi,
Thanks all for being patient, apparently I didn't quite understand the
norms of trigger execution.
On 16 May 2014 07:55, Craig Ringer wrote:
> On 05/16/2014 08:06 AM, Blagoj Petrushev wrote:
>> Hi,
>>
>> I'm thinking of an extension to trigger functionality like this:
>>
>> CREATE TRIGGER tr
On 05/16/2014 08:06 AM, Blagoj Petrushev wrote:
> Hi,
>
> I'm thinking of an extension to trigger functionality like this:
>
> CREATE TRIGGER trigger_name
> AFTER event
> ON table
> CONCURRENTLY EXECUTE PROCEDURE trigger_fc
>
> This would call the trigger after the end of the transac
Blagoj Petrushev wrote
> Hi,
>
> I'm thinking of an extension to trigger functionality like this:
>
> CREATE TRIGGER trigger_name
> AFTER event
> ON table
> CONCURRENTLY EXECUTE PROCEDURE trigger_fc
>
> This would call the trigger after the end of the transaction.
>
> The following
Hi,
I'm thinking of an extension to trigger functionality like this:
CREATE TRIGGER trigger_name
AFTER event
ON table
CONCURRENTLY EXECUTE PROCEDURE trigger_fc
This would call the trigger after the end of the transaction.
The following is a use-case, please tell me if I'm doing it w
Hello,
> Kyotaro HORIGUCHI wrote:
> > Hi, I saw this patch has been moved into "committed patches" but
> > only the first part (0001_..) for the core is committed as of
> > 32001ab but the rest for extension side seem not to have been
> > committed.
> >
> > Would you mind taking a look on that, Á
Kyotaro HORIGUCHI wrote:
> Hi, I saw this patch has been moved into "committed patches" but
> only the first part (0001_..) for the core is committed as of
> 32001ab but the rest for extension side seem not to have been
> committed.
>
> Would you mind taking a look on that, Álvaro?
Yep, pushed.
Hi, I saw this patch has been moved into "committed patches" but
only the first part (0001_..) for the core is committed as of
32001ab but the rest for extension side seem not to have been
committed.
Would you mind taking a look on that, Álvaro?
regards,
At Wed, 22 Jan 2014 17:28:27 +0900, Kyota
Hello, I came back with doc patch and revised 0002 patch.
> > > I think documentation is the only thing that stops this patch to be
> > > commitable... can you add it?
> >
> > Agreed. I have pushed patch 0001 for now.
>
> Thank you, I'll put it sooner.
I found the default setting for log_trigg
Hello,
> > > This patch consists of two parts,
> > >
> > > 0001_expose_explain_triggers_v1_20140114.patch
>
> > > 0002_auto_explain_triggers_v1_20140114.patch
>
> > > Documentation will be added later..
>
> > I think documentation is the only thing that stops this patch to be
> > commitable..
Jaime Casanova wrote:
> On Tue, Jan 14, 2014 at 4:25 AM, Kyotaro HORIGUCHI
> wrote:
> >
> > This patch consists of two parts,
> >
> > 0001_expose_explain_triggers_v1_20140114.patch
> > 0002_auto_explain_triggers_v1_20140114.patch
> > Documentation will be added later..
> I think documentation
On Tue, Jan 14, 2014 at 4:25 AM, Kyotaro HORIGUCHI
wrote:
>
> This patch consists of two parts,
>
> 0001_expose_explain_triggers_v1_20140114.patch
>
> Expose the code to print out trigger information currently
> hidden in ExplainOnePlan().
>
> 0002_auto_explain_triggers_v1_20140114.patch
>
>
Hello,
Now explain can show trigger statistics (from when?).
=# create table t (a int, b int);
=# create or replace function hoge() returns trigger as 'begin new.b = new.a;
return new; end;' language plpgsql;
=# create trigger ins_hoge before insert or update on t for each row execute
procedure
Tom Lane writes:
> This might be something to consider in the adjacent thread about command
> triggers, too --- who do they run as, and if it's not the calling user,
> how do they find out who that is?
As of now, calling user (we just calling a function), or another user if
the function is SECURI
2012/2/28 Tom Lane :
> Christopher Browne writes:
>> On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane wrote:
>>> So, whatever the desirability of having them run as table owner,
>>> we can't just up and change that.
>
>> I'm inclined to hold to the argument that it Works Properly Now, and
>> that we sho
Excerpts from Tom Lane's message of lun feb 27 20:49:36 -0300 2012:
> So (assuming Peter has read the spec correctly) I'm coming around to the
> idea that the anonymous trigger functions created by this syntax ought
> to be "SECURITY DEFINER table_owner".
I don't remember all the details, but I
Christopher Browne writes:
> On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane wrote:
>> So, whatever the desirability of having them run as table owner,
>> we can't just up and change that.
> I'm inclined to hold to the argument that it Works Properly Now, and
> that we shouldn't break it by changing i
On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> As far as I can tell, triggers run as the user performing the
>> operation which fires the trigger, not as the owner of the table.
> > Can anyone provide an example of a trigger running as the table
>> owner? Is ther
"Kevin Grittner" writes:
> As far as I can tell, triggers run as the user performing the
> operation which fires the trigger, not as the owner of the table.
> Can anyone provide an example of a trigger running as the table
> owner? Is there a bug here? Something for the docs?
A quick look into
> Kevin Grittner wrote:
>> Tom Lane wrote:
>>> By default, a trigger function runs as the table owner, ie it's
>>> implicitly SEC DEF to the table owner.
>>
>> Really? That's certainly what I would *want*, but it's not what
>> I've seen.
>>
>> [self-contained example of that not happening]
C
On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
wrote:
> That said, there's a few small things that can be progressed regardless of
> the details of synchronous replication. There's the changes to trigger
> failover with a signal, and it seems that we'll need some libpq changes to
> allow ackn
On Tue, Jun 1, 2010 at 7:10 AM, Hardik Belani wrote:
> If we introduce postgres triggers (trigger functions) on some of the tables
> to track insert/update/delete operations, (This is done by keeping and
> updating a counter field for every insert, update and delete operation
> performed on a set
On tis, 2010-06-01 at 16:40 +0530, Hardik Belani wrote:
> If we introduce postgres triggers (trigger functions) on some of the
> tables to track insert/update/delete operations, (This is done by
> keeping and updating a counter field for every insert, update and
> delete operation performed on a s
We have a multi-threaded environment in linux where multiple threads are
performing database operations(insert, update, select and at times delete as
well) in transaction mode (which may span across stored
procedures) using unixodbc. Now this as is, works fine.
If we introduce postgres triggers
Tom Lane wrote:
> > [ TRIGGER WHEN patch ]
> Applied with assorted revisions. AFAICT the system column issue is only
> a problem for NEW references in BEFORE triggers --- those columns do
> read correctly in OLD, and all the time in AFTER triggers. I revised
> the parsing logic to enforce that
Itagaki Takahiro writes:
> [ TRIGGER WHEN patch ]
Applied with assorted revisions. AFAICT the system column issue is only
a problem for NEW references in BEFORE triggers --- those columns do
read correctly in OLD, and all the time in AFTER triggers. I revised
the parsing logic to enforce that.
Itagaki Takahiro writes:
> [ TRIGGER WHEN patch ]
I'm starting to work this over now, and I've found one rather serious
omission: FreeTriggerDesc doesn't free the expression tree. This means
that trigger WHEN clauses will leak memory in CacheMemoryContext any
time we do a relcache flush on the r
Itagaki-san,
I don't have any more comments in this patch, so I hope it to be reviewed
by committers then upstreamed.
Thanks for your good jobs.
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>
>> In addition, I could find a few matters.
>> * TOAST may be necessary for pg_trigger?
>
> I added
Itagaki-san, I checked the latest patch.
It seems to me the patch getting improved from the prior version.
We are next to the commiter review phase.
But I could find a few matters. :-(
Please see the following comments, and fix it before sending it
to commiters.
> I fixed the bug and two other b
KaiGai Kohei wrote:
> Itagaki-san, I also think your example usage is enough valueable.
> However, Oracle does not have the feature apparently, although the
> purpose of this patch is to provide a compatible feature, IIRC.
>
> I don't have any preference on either of them.
> If you make a decis
Albe Laurenz wrote:
> SQL> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
> 2 BEGIN
> 3 END;
> 4 /
> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
> *
> ERROR at line 1:
> ORA-04077: WHEN clause cannot be used wit
KaiGai Kohei wrote:
> I'm uncertain how Oracle handles the condition on the statement
> triggers. But it seems to me WHEN clause on the statement triggers
> are nonsense.
SQL> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
2 BEGIN
3 END;
4 /
CREATE TRIGGER dummy BEFORE DELET
KaiGai Kohei wrote:
> Itagaki Takahiro wrote:
>> Here is a updated TRIGGER with WHEN cluase patch.
>> I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
>
> I would like to volunteer for reviewing the patch in RR-stage.
> It seems to me an interesting feature.
It seems to me you
Itagaki Takahiro wrote:
> Here is a updated TRIGGER with WHEN cluase patch.
> I adjusted it to work with recent parser cleanup (*OLD* and *NEW*).
I would like to volunteer for reviewing the patch in RR-stage.
It seems to me an interesting feature.
--
OSS Platform Development Division, NEC
KaiGai
Stephan Szabo writes:
> On Fri, 16 Oct 2009, Tom Lane wrote:
>> I note BTW that we have some ad-hoc logic already that arranges to
>> suppress queuing of AFTER events for FK triggers, if the FK column
>> value has not changed. It might be interesting to look at whether
>> that hack could be unifi
On Fri, 16 Oct 2009, Tom Lane wrote:
> I note BTW that we have some ad-hoc logic already that arranges to
> suppress queuing of AFTER events for FK triggers, if the FK column
> value has not changed. It might be interesting to look at whether
> that hack could be unified with the user-accessible
Simon Riggs writes:
> If the function is idempotent then we can also optimise away multiple
> calls by checking whether a similar call is already queued.
But how would we know that? It seems orthogonal to this patch,
anyway.
regards, tom lane
--
Sent via pgsql-hackers
On Fri, 2009-10-16 at 10:02 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> >> * It will reduce size of in-memory pending trigger list (for large
> >> statements)
>
> > But this won't be the outcome when it's implemented the way it is
Peter Eisentraut writes:
> On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
>> * It will reduce size of in-memory pending trigger list (for large
>> statements)
> But this won't be the outcome when it's implemented the way it is being
> proposed, which checks the where clause just before exe
On Fri, 2009-10-16 at 14:39 +0300, Peter Eisentraut wrote:
> On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> > * It will reduce size of in-memory pending trigger list (for large
> > statements)
>
> But this won't be the outcome when it's implemented the way it is being
> proposed, which ch
On Fri, 2009-10-16 at 09:31 +0100, Simon Riggs wrote:
> * It will reduce size of in-memory pending trigger list (for large
> statements)
But this won't be the outcome when it's implemented the way it is being
proposed, which checks the where clause just before executing the
trigger function.
--
On Fri, 2009-10-16 at 10:14 +0900, Itagaki Takahiro wrote:
> Tom Lane wrote:
>
> > Itagaki Takahiro writes:
> > > I think there is a benefit to provide WHEN cluase at least
> > > for compatibility with other DBMSs, even through we can move
> > > the expressions into the body of trigger functions
On Thu, 2009-10-15 at 16:54 -0500, Kevin Grittner wrote:
> Dimitri Fontaine wrote:
>
> > It's pretty often the case (IME) that calling a trigger is the only
> > point in the session where you fire plpgsql, and that's a visible
> > cost.
>
> Wouldn't a connection pool solve this?
No
--
Simo
Tom Lane wrote:
> Itagaki Takahiro writes:
> > I think there is a benefit to provide WHEN cluase at least
> > for compatibility with other DBMSs, even through we can move
> > the expressions into the body of trigger functions.
>
> This seems to me to be a lot of code to accomplish nothing usef
Dimitri Fontaine wrote:
> It's pretty often the case (IME) that calling a trigger is the only
> point in the session where you fire plpgsql, and that's a visible
> cost.
Wouldn't a connection pool solve this?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Tom Lane writes:
> That argument is based on a completely evidence-free assumption, namely
> that this patch would make your case faster. Executing the WHEN tests
> is hardly going to be zero cost. It's not too hard to postulate cases
> where implementing a filter this way would be *slower* than
Pavel Stehule writes:
> 2009/10/15 Tom Lane :
>> This seems to me to be a lot of code to accomplish nothing useful.
> I disagree. When I analysed speed of some operations, I found some
> unwanted trigger calls should to slow down applications. I am for any
> method, that could to decrease trigger
Itagaki Takahiro writes:
> I think there is a benefit to provide WHEN cluase at least
> for compatibility with other DBMSs, even through we can move
> the expressions into the body of trigger functions.
This seems to me to be a lot of code to accomplish nothing useful.
It will always be the case
2009/10/15 Tom Lane :
> Itagaki Takahiro writes:
>> I think there is a benefit to provide WHEN cluase at least
>> for compatibility with other DBMSs, even through we can move
>> the expressions into the body of trigger functions.
>
> This seems to me to be a lot of code to accomplish nothing usefu
Michael Nacos writes:
> The interesting thing is SQL_exec(sql,1) resulted in a different
> execution plan while the stray FROM was still in place.
Well, the stray FROM resulted in a useless cross-join, which would
have generated a lot of extra no-op row updates. I think what the
limit was doing
This is from within SPI_exec:
Nested Loop (cost=0.00..115947.18 rows=1952242 width=25) (actual
time=0.095..6425.291 rows=1952202 loops=1)
-> Index Scan using othertable_level_pkey on othertable
(cost=0.00..9.34 rows=1 width=25) (actual time=0.063..0.067 rows=1
loops=1)
Index Cond: ((le
Michael Nacos writes:
> the only thing I can tell from EXPLAIN ANALYZE is how long the trigger took
I was thinking of doing EXPLAIN ANALYZE via SPI_exec and seeing if you
got the same results as doing it manually.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hi Tom,
the only thing I can tell from EXPLAIN ANALYZE is how long the trigger took
Index Scan using some_pkey on sometable (cost=0.00..8.58 rows=1 width=253)
(actual time=0.046..0.050 rows=1 loops=1)
Index Cond: (pkey = 123456)
Trigger so_and_so_on_change: time=62.309 calls=1
running an equ
Michael Nacos writes:
> I have been trying to improve the performance of a C trigger only to notice
> that the real bottleneck was the SPI execution of dynamic SQL statements. I
> had been using SPI_exec(sql,0) until I tried SPI_exec(sql,1), since I am
> targeting exactly one row each time for wri
Hi all,
I have been trying to improve the performance of a C trigger only to notice
that the real bottleneck was the SPI execution of dynamic SQL statements. I
had been using SPI_exec(sql,0) until I tried SPI_exec(sql,1), since I am
targeting exactly one row each time for writing. This simple chan
Peter Eisentraut writes:
> Is there a reason why the function manager allows calling trigger functions
> outside of triggers and forces the PLs to catch this case themselves? Is
> there a case where calling trigger functions directly is useful?
I think it's a matter of not wanting to slow down
Is there a reason why the function manager allows calling trigger functions
outside of triggers and forces the PLs to catch this case themselves? Is
there a case where calling trigger functions directly is useful?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Wed, 2008-10-08 at 20:56 +0200, A. Kretschmer wrote:
> am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes:
> > Hi,
> >
> > Trigger functions are supposed to be able to be called only as triggers,
> > but apparently the check is not working in CVS HEAD:
> >
> > alvherre=
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Trigger functions are supposed to be able to be called only as triggers,
> but apparently the check is not working in CVS HEAD:
I traced through this, and what is happening is that the validator's
trial compilation of the function doesn't complain (as i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Trigger functions are supposed to be able to be called only as triggers,
> but apparently the check is not working in CVS HEAD:
Hmm, some experimentation shows that 7.4 is the only active branch that
throws an error for that. Did we change it intention
A. Kretschmer wrote:
> am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes:
> > Hi,
> >
> > Trigger functions are supposed to be able to be called only as triggers,
> > but apparently the check is not working in CVS HEAD:
> >
> > alvherre=# create or replace function foo ()
On Wed, Oct 8, 2008 at 3:56 PM, A. Kretschmer
<[EMAIL PROTECTED]> wrote:
> am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes:
>> Hi,
>>
>> Trigger functions are supposed to be able to be called only as triggers,
>> but apparently the check is not working in CVS HEAD:
>>
>>
am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes:
> Hi,
>
> Trigger functions are supposed to be able to be called only as triggers,
> but apparently the check is not working in CVS HEAD:
>
> alvherre=# create or replace function foo () returns trigger as $$ begin
> per
I get the same thing on 8.2.9.
...Robert
On Wed, Oct 8, 2008 at 2:29 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Trigger functions are supposed to be able to be called only as triggers,
> but apparently the check is not working in CVS HEAD:
>
> alvherre=# create or replace function fo
Hi,
Trigger functions are supposed to be able to be called only as triggers,
but apparently the check is not working in CVS HEAD:
alvherre=# create or replace function foo () returns trigger as $$ begin
perform 1; return new; end; $$ language plpgsql;
CREATE FUNCTION
alvherre=# select foo();
fo
Currently, there is a limitation in PostgreSQL that any ON SELECT RULE must be
an unconditional SELECT action that is INSTEAD.
The reasoning is "This restriction was required to make rules safe enough to
open them for ordinary users, and it restricts ON SELECT rules to act like
views."
I cann
Nikolay Grebnev wrote:
Good Day,
I recently posted a message here
(http://archives.postgresql.org/pgsql-hackers/2007-12/msg00340.php)
that the trigger does not work as it should from time to time. Now the
trigger works on C, before It was on TCL and it had the same problem.
As the trigger w
Good Day,
I recently posted a message here (
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00340.php) that the
trigger does not work as it should from time to time. Now the trigger works
on C, before It was on TCL and it had the same problem.
As the trigger works all right in 99.999 % ca
Good day,
We have written a trigger that is
We have written a trigger that is associated with the table. When any
changes are submitted, then this trigger reconstruct and writes sql query to
the table querieslog.
We have found a problem: from time to time some sql query is not written
while the q
Tom Lane wrote:
Why not?
The real answer is "it's historical and I didn't see any need to
change it". But one could argue that a function returning NULL
doesn't know it's supposed to be a trigger.
The reason I ask is that this behavior just bit me in PL/Java. Triggers
returning null didn't wor
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Perhaps you should either change this behavior or make a note it in
> "Writing Trigger Functions in C"?
Okay, I've changed the text thusly:
diff -r1.35 trigger.sgml
434,435c434,437
< A trigger function must return either NULL or a
< HeapTuple
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> In backend/commands/trigger.c the following can be found:
> /*
> * Trigger protocol allows function to return a null pointer,
> * but NOT to set the isnull result flag.
> */
> if (fcinfo.isnull)
> ereport(ERROR,
> W
In backend/commands/trigger.c the following can be found:
/*
* Trigger protocol allows function to return a null pointer,
* but NOT to set the isnull result flag.
*/
if (fcinfo.isnull)
ereport(ERROR,
Why?
Regards,
Thomas Hallgren
---(end of bro
I am using table inheritance and it simplifies things for me a lot, but there
is one thing that is missing: trigger inheritance (I do not mean constraint
triggers).
So far I wrote function that copy all non-constraint triggers from parent to
child table, but I must call that function
On Thursday 13 May 2004 10:01 am, shiva chetan wrote:
(B>
(B> Where can I find information about the trigger execution model of
(B> postgresql ? In particular I want to know how triggers are fired when an
(B> update happens in the database. Is the trigger evaluation and firing part
(B> of tran
Hi,
Where can I find information about the trigger execution
model of postgresql ? In particular I want to know how triggers are fired when
an update happens in the database. Is the trigger evaluation and firing part of
transaction ? Please let me know where I can find more information
Paul Ramsey <[EMAIL PROTECTED]> writes:
> Now, if we changed the geometry type so that when one defined a geometry
> column, one had to include info about what SRID and what dimension it
> was, (ala varchar(243)) maybe the whole schmeer could reside in pg_class
> and geometry_columns would be a
So close... It is a testament to my blockheadedness that I had not
considered that (Dave probably did). Here is the standards-mandated
definition of the table:
CREATE TABLE GEOMETRY_COLUMNS (
F_TABLE_CATALOG VARCHAR(256) NOT NULL,
F_TABLE_SCHEMA VARCHAR(256) NOT NULL,
F_TABLE_NAME VARCHAR(
Paul Ramsey <[EMAIL PROTECTED]> writes:
> We have a similar requirement for PostGIS.
> In order to meet the OpenGIS specification, we have to maintain a
> GEOMETRY_COLUMNS table which includes an entry for every column in the
> db which holds a spatial column. It would be ideal if we could have
Paul Ramsey writes:
> In order to meet the OpenGIS specification, we have to maintain a
> GEOMETRY_COLUMNS table which includes an entry for every column in the
> db which holds a spatial column.
Why not make a view?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of b
We have a similar requirement for PostGIS.
In order to meet the OpenGIS specification, we have to maintain a
GEOMETRY_COLUMNS table which includes an entry for every column in the
db which holds a spatial column. It would be ideal if we could have
triggers run on CREATE TABLE, DROP TABLE, and AL
Sorry, I can't think of any to have a view created automatically for
every table creation. Interesting idea, though. I wonder if you could
pass the CREATE string into a function that does the proper creation.
---
Bruce Dav
All,
I'm trying to implement row level security using PostgreSQL. I envision
having column on each and every table in the database that will contain a
discriminating value that determines if a given user is able to see that row
or not. Users do not directly access the database; they get at it on
On Thursday 03 October 2002 02:31 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> One thing that confuses me though is that the build options have been
> like this for a long time (at least since 7.1). Why haven't you seen
> this problem before? Did you recently change the way the
Lamar Owen <[EMAIL PROTECTED]> writes:
> So the regression tests weren't really testing the actually built module, so
> to speak. Is there a good reason to leave the NOTICE's in the expected
> regression output?
Yes: without them the test is less useful, because you're less certain
that what h
On Thursday 03 October 2002 12:46 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Builds fine here for RPM usage. Got an odd diff in the triggers
> > regression test: did we drop a NOTICE? If so, the regression output
> > should probably have been changed too. The diff:
> > ***
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> This will work nicely for the regression tests' purposes. If there is
> >> anyone out there actually using refint.c in production, they might be
> >> annoyed by the NOTICE chatter, but quite honestly I doubt anyo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This will work nicely for the regression tests' purposes. If there is
>> anyone out there actually using refint.c in production, they might be
>> annoyed by the NOTICE chatter, but quite honestly I doubt anyone is ---
>> this contrib
Tom Lane wrote:
> I said:
> > I am inclined to have the refint.c code emit the notice unconditionally
> > at DEBUG1 level, and then add a "SET client_min_messages = DEBUG1" in
> > the triggers regression test to ensure the notice will appear.
>
> Hmm, that doesn't look that good after all: the SE
I said:
> I am inclined to have the refint.c code emit the notice unconditionally
> at DEBUG1 level, and then add a "SET client_min_messages = DEBUG1" in
> the triggers regression test to ensure the notice will appear.
Hmm, that doesn't look that good after all: the SET causes the
regression outp
Lamar Owen <[EMAIL PROTECTED]> writes:
> Builds fine here for RPM usage. Got an odd diff in the triggers regression
> test: did we drop a NOTICE? If so, the regression output should probably
> have been changed too. The diff:
> *** ./expected/triggers.out Sat Jan 15 14:18:23 2000
> --- ./
I have written some triggers which will call some
procedures.
I am looking for some way wherein I can edit
these procedures
Is there any way to do so?
regards,
joseph
hello all
Anyone knows a way to get the machine that execute the query?
thanks ...
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
jreniz <[EMAIL PROTECTED]> writes:
> So, when I run this trigger there is a mistake:
> ''there is no operator '=$' for types 'int4' and 'int4'
> (My system is 6.5.3)
This is an old bug. Update to 7.0.3.
It might work to add spaces around the '=' signs in your trigger
function, but an update w
Hi friends!
I'm working in a trigger and I need to put the result
of a query into a variable.
That's very easy- apparently!
The query has a aggregate function like this:
select sum(field) into variable ...
and I'm sure that field and variable are int4 type.
So, when I run this trigger there
> Comments anyone?
Yes Bruce, I already told about it with Peter in private mails. Because
it's 1/2 of year and nobody answer I already start work on PL/Python.
The PL/Python will in 7.2 - as soon as I can I send some proposal to
hackers list.
Karel
> >
>
Comments anyone?
>
> On Tue, 19 Dec 2000, Bruce Momjian wrote:
>
> > > PS. -hackers: What happen with PL/Python? Before 1/2 of year I ask if
> > > anyone works on this and answer was: "yes, but 'he' is waiting for new
> > > fmgr design". Tom's fmgr is done... IMHO it's big worse - Th
Karel Zak wrote:
>
> On Tue, 19 Dec 2000, Bruce Momjian wrote:
>
> > > PS. -hackers: What happen with PL/Python? Before 1/2 of year I ask if
> > > anyone works on this and answer was: "yes, but 'he' is waiting for new
> > > fmgr design". Tom's fmgr is done... IMHO it's big worse - The Py
On Tue, 19 Dec 2000, Bruce Momjian wrote:
> > PS. -hackers: What happen with PL/Python? Before 1/2 of year I ask if
> > anyone works on this and answer was: "yes, but 'he' is waiting for new
> > fmgr design". Tom's fmgr is done... IMHO it's big worse - The Python
> > has very good
> PS. -hackers: What happen with PL/Python? Before 1/2 of year I ask if
> anyone works on this and answer was: "yes, but 'he' is waiting for new
> fmgr design". Tom's fmgr is done... IMHO it's big worse - The Python
> has very good design for integration to other programs.
Good que
On Fri, 15 Dec 2000, Manika dey wrote:
>
> Hi,
> Can anyone help me .
> I want to know how
> to write triggers.
> i am using java and postgresql
not probably in java you can write function in some
"internal-interpreted-language": C, Perl, Tcl, SQL, PL/SQL
BTW, What is bad on PostgreSQL
1 - 100 of 102 matches
Mail list logo
