On Fri, 17 Mar 2006, Jeff Frost wrote:
I'll try that and see if that makes the difference, since we're recreating
(create or replace) that function in that transaction anyway, but perhaps
that needs to happen before the update.
I added this at the top of the transaction:
DROP FUNCTION public
On Sat, 18 Mar 2006, Tom Lane wrote:
Is that the case whether the triggers are executed or not?
If the trigger function hasn't ever been executed in the current
session, it wouldn't have a cached plan ... but I suspect you meant
"if it hasn't been executed in the current transaction", and that
On Sat, 18 Mar 2006, Tom Lane wrote:
No, I think it's that you've got a plpgsql trigger function that
contains queries referring to credit_card_audit. Dropping and
recreating that table invalidates plpgsql's cached plans for those
queries.
Is that the case whether the triggers are executed or
Jeff Frost <[EMAIL PROTECTED]> writes:
> On Sat, 18 Mar 2006, Tom Lane wrote:
>> No, I think it's that you've got a plpgsql trigger function that
>> contains queries referring to credit_card_audit. Dropping and
>> recreating that table invalidates plpgsql's cached plans for those
>> queries.
> Is
Jeff Frost <[EMAIL PROTECTED]> writes:
> I suspect I've answered my own question while preparing the test case. Is it
> the use of pg_get_serial_sequence at the bottom of the transaction? If so,
> why does it only have a problem when there is an update to credit_card_audit
> in the transaction?
On Fri, 17 Mar 2006, Jeff Frost wrote:
Could we see a complete test case, rather than handwaving? I'd expect
some issues like this if you were using any prepared statements or
plpgsql functions with non-EXECUTEd queries involving the dropped table,
but your description doesn't mention either of
On Fri, 17 Mar 2006, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
After commit, I get a lovely:
ERROR: could not open relation with OID x
Could we see a complete test case, rather than handwaving? I'd expect
some issues like this if you were using any prepared statements or
plpg
Jeff Frost <[EMAIL PROTECTED]> writes:
> After commit, I get a lovely:
> ERROR: could not open relation with OID x
Could we see a complete test case, rather than handwaving? I'd expect
some issues like this if you were using any prepared statements or
plpgsql functions with non-EXECUTEd querie
Not sure if this is the best list for this issue, but I ran into something
that I thought should work inside a transaction, but obviously PostgreSQL
thought otherwise.
Postgres version is 8.1.3. The transaction I wrote is basically:
BEGIN;
DROP RULE foo_audit_no_update ON foo_audit;
UPDATE f
On Friday 17 March 2006 15:33, Emi Lu wrote:
> >>Does not work either, the whole function is:
> >>
> >>create table t1(col1 varchar(3), col2 varchar(100));
> >>insert into t1 values('001', 'Result 1');
> >>insert into t1 values('002', 'Result 2');
> >>insert into t1 values('003', 'Result 3');
> >>
Does not work either, the whole function is:
create table t1(col1 varchar(3), col2 varchar(100));
insert into t1 values('001', 'Result 1');
insert into t1 values('002', 'Result 2');
insert into t1 values('003', 'Result 3');
CREATE OR REPLACE FUNCTION test(VARCHAR) RETURNS VARCHAR AS $$
DECLARE
am 17.03.2006, um 14:23:57 -0500 mailte Emi Lu folgendes:
> Does not work either, the whole function is:
>
> create table t1(col1 varchar(3), col2 varchar(100));
> insert into t1 values('001', 'Result 1');
> insert into t1 values('002', 'Result 2');
> insert into t1 values('003', 'Result 3');
>
Does not work either, the whole function is:
create table t1(col1 varchar(3), col2 varchar(100));
insert into t1 values('001', 'Result 1');
insert into t1 values('002', 'Result 2');
insert into t1 values('003', 'Result 3');
CREATE OR REPLACE FUNCTION test(VARCHAR) RETURNS VARCHAR AS $$
DECLARE
Hello,
In pl/pgsql (postgresql 8.01), how to use variables in select .. into ..
command
CREATE OR REPLACE FUNCTION test(VARCHAR) RETURNS VARCHAR AS $$
DECLARE
var1 ALIAS FOR $1;
cm_tableName tableA.col1%TYPE;
T1
Hi, Marciej,
Maciej Piekielniak wrote:
> TL> Use 8.1's pg_dump and pg_dumpall to dump from the old server. We fixed
> TL> that problem finally.
>
> I try to copy pg_wrapper,PgCommon.pm to /usr/bin but when i type
> pg_dump -V i got:
> Argument "." isn't numeric in numeric lt(<) at PgCommo
Hy list,
I would like to check if date is inside a given date range.
For instance if date range is
datestart column: 10/10/2005
dateend column: 10/20/2005
I would like to return columns for date = 10/15/2005 and not if i enter
let's say date = 10/21/2005
thanks for your help,
Jure Kodzoman
> I would like to check if date is inside a given date range.
stupid question :) sorry for bothering you.
Jure
>
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
O [EMAIL PROTECTED] έγραψε στις Mar 17, 2006 :
> >
> >SELECT c1.relname,c2.relname from pg_constraint cons,pg_class c1,
> pg_class
> >c2 where cons.conrelid=c1.oid and cons.confrelid = c2.oid;
> >
> >for column(s) names you will have to do extra homework.
>
> Thanks! I have obtained my query!
O [EMAIL PROTECTED] έγραψε στις Mar 16, 2006 :
> > pg_catalog.pg_constraint is your (only?) friend.
>
> I have already examintated this table without results. Seem not to be
> a "human-readable" table :(
Right you will have to join against pg_class,
and make it readable.
SELECT c1.reln
Emi Lu wrote:
From the page:
"The PL/pgSQL condition name for each error code is the same as the
phrase shown in the table, with underscores substituted for spaces.
For example, code 22012, DIVISION BY ZERO, has condition name
DIVISION_BY_ZERO. Condition names can be written in either upper
20 matches
Mail list logo
