[HACKERS] Commit a445cb92 not tested without OpenSSL support?
Hey folks It appears that the commit a445cb92ef5b3a31313ebce30e18cc1d6e0bdecb causes ld to bail when building *without* OpenSSL support: utils/misc/guc.o:(.data+0x4d80): undefined reference to `ssl_cert_file' utils/misc/guc.o:(.data+0x4ddc): undefined reference to `ssl_key_file' utils/misc/guc.o:(.data+0x4e38): undefined reference to `ssl_ca_file' utils/misc/guc.o:(.data+0x4e94): undefined reference to `ssl_crl_file' Tested; the conditional compilation predicated upon #ifdef USE_SSL in be-secure.c is satisfied with configure (--)with(-)openssl to succeed. Regards, Affan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql and qualified variable names
ISTM supporting somefunc.ambiguous just gives us another way to reference the parameter, and there still isn't any way to refer the column. Could we not, at least, support explicit column disambiguation? e.g. This PL/SQL procedure: CREATE OR REPLACE PROCEDURE insert_emp (empno emp.empno%TYPE, ename emp.ename%TYPE) IS BEGIN INSERT INTO emp (empno, ename) VALUES (empno, ename); END; is tantamount to writing this: CREATE OR REPLACE PROCEDURE insert_emp (empno emp.empno%TYPE, ename emp.ename%TYPE) IS BEGIN INSERT INTO emp (emp.empno, emp.ename) VALUES (insert_emp.empno, insert_emp.ename); END; Both are valid, and notice how the latter evinces disambiguation supported both ways. -- Affan Salman EnterpriseDB Corporation http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FK Deferred RI Triggers SAVEPOINTs --- ACID violation
Patch submitted. -- Affan Salman EnterpriseDB Corporation http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] FK Deferred RI Triggers SAVEPOINTs --- ACID violation
I think I have stumbled across a bug here;
While skipping queuing of an RI trigger for a non-FK UPDATE, the
non-optimizable exception check (see below) in trigger.c @
AfterTriggerSaveEvent() fails to handle SAVEPOINTs correctly and can
jovially leave inconsistent data behind at transaction completion:
case RI_TRIGGER_FK:
/*
* Update on FK table
*
* There is one exception when updating FK tables: if the
* updated row was inserted by our own transaction and the
* FK is deferred, we still need to fire the trigger. This
* is because our UPDATE will invalidate the INSERT so the
* end-of-transaction INSERT RI trigger will not do
* anything, so we have to do the check for the UPDATE
* anyway.
*/
if (HeapTupleHeaderGetXmin(oldtup-t_data) !=
GetCurrentTransactionId()
RI_FKey_keyequal_upd_fk(trigger, rel, oldtup, newtup))
{
continue;
}
break;
A slightly modified version of a *well-written* test case in
the foreign_key regression test category can exhibit this:
-- test a tricky case: we can elide firing the FK check trigger during
-- an UPDATE if the UPDATE did not change the foreign key
-- field. However, we can't do this if our transaction was the one that
-- created the updated row and the trigger is deferred, since our UPDATE
-- will have invalidated the original newly-inserted tuple, and therefore
-- cause the on-INSERT RI trigger not to be fired.
CREATE TEMP TABLE pktable (
id int primary key,
other int
);
CREATE TEMP TABLE fktable (
id int primary key,
fk int references pktable deferrable initially deferred
);
INSERT INTO pktable VALUES (5, 10);
BEGIN;
SAVEPOINT insertSavePoint;
-- doesn't match PK, but no error yet
INSERT INTO fktable VALUES (0, 20);
SAVEPOINT updateSavePoint;
-- don't change FK
UPDATE fktable SET id = id + 1;
-- should catch error from initial INSERT
COMMIT;
Since the old tuple Xmin was assigned the XID for *insertSavePoint
subxact*; at the UPDATE FK trigger event queuing time it is compared
with the XID for *updateSavePoint subxact* and results in missing a
requisite RI check.
--
Affan Salman
EnterpriseDB Corporationhttp://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] SQL99 - Nested Tables
On 7/7/05, Darren Alcorn [EMAIL PROTECTED] wrote: I was interested as to if there were plans to develop SQL99 nested tables. I know with AJAX(tm) starting to grow in popularity that the XML features of SQL2003 would prove useful for EnterpriseDB. Although this discussion seems to be heading more towards Nested Tables, I would like to express that EnterpriseDB is very interested in seeing XML features of SQL2003 specs added to PostgreSQL. We would love to sponsor anybody possessing the pertinent skillset and interested in working on these bi-directional mapping features. This, of course, includes folks already working on any XML-oriented projects for PostgreSQL. If you are interested, drop a private e-mail to Denis Lussier ([EMAIL PROTECTED]). Affan Bin Salman, Lead Database Architect EnterpriseDB Corporation. mailto: [EMAIL PROTECTED] blog: http://affans.blogspot.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] SQL99 - Nested Tables
On 7/7/05, David Fetter [EMAIL PROTECTED] wrote: It would need to be a fairly strong one, given that they basically violate the relational model. If what you're really interested in is XML data support, then I'd suggest focusing on that instead. XML data support would be best if coordinated. There are several different projects right now, and one more would be bad. David, Can you enumerate or refer to these *apparently* uncoordianted/disparate XML data support projects? I would also appreciate any progress/status information on 'em, if possible. Thanks, Affan Bin Salman, Lead Database Architect EnterpriseDB Corporation. mailto: [EMAIL PROTECTED] blog: http://affans.blogspot.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
