[Phplib-users] db_pgsql metadata & question on auth

[Oliver Duke-W. <ol...@ge...>]

Hi,

[Using phplib 7.2d w/ php 4.0.6]

I've encountered a problem with the function db_pgsql->metadata(); the
function derives its information by doing "select * from $table", which can
take a long time on a large table, and also choke the memory if the table is
large enough.  

Am I missing anything obvious if I change it to 'select * from $table limit
0'?  This will cause only the field metadata to be returned, and performance
will not therefore be dependent on the table size.  This works for the example
I'm currently playing with, and I can't see why it should fail anywhere else.

Having said, that it may be that the best performance would be gained by using
the pg_ catalog tables, in the same way that psql does; i.e. the metadata
could be retrieved as:

SELECT a.attname,format_type(a.atttypid, a.atttypmod),a.attlen 
FROM pg_class c, pg_attribute a 
WHERE c.relname = $table 
AND a.attrelid = c.oid and a.attnum > 0 
ORDER BY a.attnum

However, I'm not sure whether any performance gain would be noticeable...

On a completely unrelated issue, I've had a problem trying to use a 'cancel'
button on a login form if I set register_globals to 'off' in php.  (I'm using
a default auth, and including a 'login' button on each page, which then
includes a login form via the login_if())

The auth code as is checks for the existence of the value indicated by
$auth->cancel_login; however given that the http variables do not get
automatically globally imported, this check fails.

I've tried pretty numerous permutations of setting cancel_login in my local
extension of auth to e.g. HTTP_POST_VARS['my_button_name'], but without
success.  Instead the only way I've been able to use the button is by changing
line 72 of the original auth.inc from:

          if ($$cl) {

to:

          if (isset ($GLOBALS['HTTP_POST_VARS'][$cl])) {

which is not as generalised as one might like, and certainly seems to be the
wrong way of solving the problem.

Can anyone suggest the 'correct' way to do this?

Cheers,

Oliver
-- 
Oliver Duke-Williams  <ol...@ge...>   Tel 0113 233 3286
Centre for Computational Geography, University of Leeds, UK