| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Meskes <meskes(at)postgresql(dot)org> |
| Cc: | Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 7.3beta and ecpg |
| Date: | 2002-09-12 13:07:20 |
| Message-ID: | 5110.1031836040@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Meskes <meskes(at)postgresql(dot)org> writes:
> I'm awfully sorry that I missed this thread. But I do not really
> understand the problem. If we cannot be exactly as specified why aren't
> we coming close? As it stands now I have to implement my own
> PREPARE/EXECUTE in ecpg and the syntax does clash with the backend one.
But you must implement your own PREPARE/EXECUTE anyway, using ecpg
variables, no? If you can really embed what you need in the backend
facility, and only the syntax variation is getting in the way, then
maybe I misunderstand the problem. How do parameters of PREPAREd
statements work in ecpg?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-09-12 14:14:46 | Re: DROP COLUMN misbehaviour with multiple inheritance |
| Previous Message | Zbigniew Lukasiak | 2002-09-12 12:51:25 | UTF-8 collation (was Re: [BUGS] LATIN2 ORDER BY) |