Обсуждение: Trigger Display Bugs in 1.12 pgAdmin
To Who It May Concern, I am using the new 1.12 pgAdmin on Windows XP SP3 and I have notice two display inaccuracies when connecting to a Postgres9 database. For example when creating the following trigger: CREATE TRIGGER c_aud_trg BEFORE INSERT OR UPDATE OR DELETE ON ca FOR EACH ROW EXECUTE PROCEDURE c_aud_trg_trfunc(); It will get created correctly (checking with pgdump based on suggestions from the pgsql list). However it will be displayed as:CREATE TRIGGER c_aud_trg BEFORE INSERT OR UPDATE ON ca FOR EACH ROW EXECUTE PROCEDUREc_aud_trg_func(E'\\x'); If that same trigger is dropped and re-added using what is in the database, the following shows up:CREATE TRIGGER c_aud_trg BEFORE INSERT OR UPDATE ON ca FOR EACH ROW EXECUTE PROCEDURE c_aud_trg_func(E'\\x5c7800'); The second issue is the ordering of 'update of' triggers. For example when creating the following trigger: CREATE TRIGGER ca_trig BEFORE UPDATE OF columnA OR DELETE ON ca FOR EACH ROW EXECUTE PROCEDURE c_h_trg_func (); It will be displayed as: CREATE TRIGGER ca_trig BEFORE UPDATE OR DELETE OF columnA ON ca FOR EACH ROW EXECUTE PROCEDURE c_h_trg_func (); This is a syntax error. On a side note, does pgAdmin or Postgres have a bug tracker like bugzilla/trac/jira/etc? Christopher A Hotchkiss JPMorgan Chase & Co. Email christopher.a.hotchkiss@jpmchase.com This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
Hi,
Le 24/09/2010 21:26, Christopher A Hotchkiss a écrit :
> To Who It May Concern,
> I am using the new 1.12 pgAdmin on Windows XP SP3 and I have notice two display inaccuracies when connecting to a
Postgres9 database.
>
> For example when creating the following trigger:
>
> CREATE TRIGGER c_aud_trg
> BEFORE INSERT OR UPDATE OR DELETE
> ON ca
> FOR EACH ROW
> EXECUTE PROCEDURE c_aud_trg_trfunc();
>
> It will get created correctly (checking with pgdump based on suggestions from the pgsql list).
>
> However it will be displayed as:
> CREATE TRIGGER c_aud_trg
> BEFORE INSERT OR UPDATE
> ON ca
> FOR EACH ROW
> EXECUTE PROCEDURE c_aud_trg_func(E'\\x');
>
> If that same trigger is dropped and re-added using what is in the database, the following shows up:
> CREATE TRIGGER c_aud_trg
> BEFORE INSERT OR UPDATE
> ON ca
> FOR EACH ROW
> EXECUTE PROCEDURE c_aud_trg_func(E'\\x5c7800');
>
Your specific issue is quite easy to fix. It's done on the attached patch.
Unfortunately, it shows another issue. The issue I found relates to the
new GUC bytea_output. Here is a quick example.
ticketx=# CREATE TRIGGER c_aud_trg2
BEFORE INSERT OR UPDATE OR DELETE
ON ca
FOR EACH ROW
EXECUTE PROCEDURE c_aud_trg_trfunc2('&');
This statement creates a trigger that executes a procedure which accepts
one argument. Let's try to get the contents of the column tgargs of the
pg_trigger table:
ticketx=# select tgargs from pg_trigger where tgname='c_aud_trg2';
tgargs
--------
\x2600
(1 row)
This is the new hex output for a bytea column (yes, tgargs is a bytea).
Let's try the old output:
ticketx=# set bytea_output to escape;
SET
ticketx=# select tgargs from pg_trigger where tgname='c_aud_trg2';
tgargs
--------
&\000
(1 row)
Much better. So, the only way to fix this, AFAICT, is to set bytea_ouput
to "escape" when connected to a 9.0 server. My question is this: should
I set the parameter at the connection start, or should I set and unset
it during the search of triggers? The latter is less error prone, but
requires to execute three more queries (SHOW bytea_output, SET
bytea_output TO escape, SET bytea_output TO old_value).
> The second issue is the ordering of 'update of' triggers. For example when creating the following trigger:
> CREATE TRIGGER ca_trig
> BEFORE UPDATE OF columnA OR DELETE
> ON ca
> FOR EACH ROW
> EXECUTE PROCEDURE c_h_trg_func ();
>
> It will be displayed as:
> CREATE TRIGGER ca_trig
> BEFORE UPDATE OR DELETE OF columnA
> ON ca
> FOR EACH ROW
> EXECUTE PROCEDURE c_h_trg_func ();
>
> This is a syntax error.
>
Fixed on the attached patch.
> On a side note, does pgAdmin or Postgres have a bug tracker like bugzilla/trac/jira/etc?
>
Postgres doesn't. pgAdmin has one, but it's readonly for most people.
Usually, I put in it each bug I'm able to reproduce. It's available at
http://code.pgadmin.org/, and your issue is here:
http://code.pgadmin.org/trac/ticket/240
Thanks for your report.
--
Guillaume
http://www.postgresql.fr
http://dalibo.com
On Fri, Sep 24, 2010 at 11:54 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Much better. So, the only way to fix this, AFAICT, is to set bytea_ouput > to "escape" when connected to a 9.0 server. My question is this: should > I set the parameter at the connection start, or should I set and unset > it during the search of triggers? The latter is less error prone, but > requires to execute three more queries (SHOW bytea_output, SET > bytea_output TO escape, SET bytea_output TO old_value). Please set at connection. The old output is what all the rest of the code expects (if anywhere does expect it), so I can't imagine it would break anything. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 25/09/2010 01:09, Dave Page a écrit : > On Fri, Sep 24, 2010 at 11:54 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > >> Much better. So, the only way to fix this, AFAICT, is to set bytea_ouput >> to "escape" when connected to a 9.0 server. My question is this: should >> I set the parameter at the connection start, or should I set and unset >> it during the search of triggers? The latter is less error prone, but >> requires to execute three more queries (SHOW bytea_output, SET >> bytea_output TO escape, SET bytea_output TO old_value). > > Please set at connection. The old output is what all the rest of the > code expects (if anywhere does expect it), so I can't imagine it would > break anything. > OK, that was also my favorite solution. Just pushed my commits on 1.12 and master. Thanks. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
>Le 25/09/2010 01:09, Dave Page a écrit : >> On Fri, Sep 24, 2010 at 11:54 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >> >>> Much better. So, the only way to fix this, AFAICT, is to set bytea_ouput >>> to "escape" when connected to a 9.0 server. My question is this: should >>> I set the parameter at the connection start, or should I set and unset >>> it during the search of triggers? The latter is less error prone, but >>> requires to execute three more queries (SHOW bytea_output, SET >>> bytea_output TO escape, SET bytea_output TO old_value). >> >> Please set at connection. The old output is what all the rest of the >> code expects (if anywhere does expect it), so I can't imagine it would >> break anything. >> > >OK, that was also my favorite solution. Just pushed my commits on 1.12 >and master. > Guillaume, Thank you for the quick fix! Christopher A Hotchkiss JPMorgan Chase & Co. Email christopher.a.hotchkiss@jpmchase.com This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.