Thread: Suggestions for an update to the PHP manual?

Suggestions for an update to the PHP manual?

From
Justin Clift
Date:
Hi everyone,

Just downloaded the PHP Manual, and noticed in Chapter 47 (directly part
of the FAQ) there is a section titled "2. Can I access Microsoft Access
databases?"

I has quite an extensive step by step approach for access MS Access
databases through MySQL, links to the MySQL homepage, etc.  In short,
probably a very effective customer generator for MySQL.

Does anyone out there feel like making the same kind of thing for
PostgreSQL and submitting it to the PHP team for inclusion in the PHP
manual here as well?  In the past they've put in things we've submitted
to them, so I don't feel it would be ignored (and it would be useful).

I reckon it would be useful.

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi



Update question and SQL question

From
Steve Lane
Date:
Hello all:

Two unrelated questions.

1. I needed to do an update to a table called iep_form_002. It has a number
of triggers on it. The update was to a single field, which is not involved
in any way in any of the triggers. When I executed the update, I got the
message

NOTICE:  Error occurred while executing PL/pgSQL function
lookup_name_district
NOTICE:  line 1 at select into variables
ERROR:  record student_rec is unassigned yet

lookup_name_district is defined as follows:

DECLARE student_rec record; BEGIN SELECT INTO student_rec * FROM iep_student
WHERE id_student = new.id_student; SELECT INTO new.name_district
name_district FROM iep_district WHERE id_county = student_rec.id_county AND
id_district = student_rec.id_district; RETURN new; END;

I had seen earlier references to this problem. Something I read led me to
think that upgrading to 7.2 (from 7.1) would make this go away, but it
didn't. Temporarily disabling all triggers on the table worked just fine.

So I'm guess there's something systematically off in the way I'm doing
triggers. Any clues? I can provide more info if necessary, of course.

2. I thought I had understood the SQL standard to say that using AS when
making column aliases was always optional, yet in postgres I encounter cases
where I must use it or a parse error results. As far as I can tell, these
cases only occur when I'm aliasing a column that has some kind of function
or aggregate. so:

iep_db=# select name_list_guardian, length(name_list_guardian) l from
iep_form_001;
ERROR:  parser: parse error at or near "l"
iep_db=# select name_list_guardian, length(name_list_guardian) as l from
iep_form_001;

The second form of this works. Am I just misremembering SQL?

Thanks,

Steve





Re: Update question and SQL question

From
Tom Lane
Date:
Steve Lane <slane@fmpro.com> writes:
> NOTICE:  Error occurred while executing PL/pgSQL function
> lookup_name_district
> NOTICE:  line 1 at select into variables
> ERROR:  record student_rec is unassigned yet

Hm.  Could we see a complete example (eg, a runnable psql script to set
up the tables and the function and cause the error)?  Trying to fill in
the missing pieces is no fun.

> 2. I thought I had understood the SQL standard to say that using AS when
> making column aliases was always optional,

The spec says that, but AS is always required for a column alias in PG.
See the "Compatibility" discussion on the SELECT reference page.

            regards, tom lane