@@ -171,3 +171,205 @@ advertising :-)
171
171
172
172
173
173
174
+ From pgsql-hackers-owner+M312@postgresql.org Mon Nov 6 03:27:32 2000
175
+ Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
176
+ by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id DAA28404
177
+ for <pgman@candle.pha.pa.us>; Mon, 6 Nov 2000 03:27:32 -0500 (EST)
178
+ Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
179
+ by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eA68Pos51966;
180
+ Mon, 6 Nov 2000 03:25:50 -0500 (EST)
181
+ (envelope-from pgsql-hackers-owner+M312@postgresql.org)
182
+ Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4])
183
+ by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eA68Fes50414
184
+ for <pgsql-hackers@postgresql.org>; Mon, 6 Nov 2000 03:15:40 -0500 (EST)
185
+ (envelope-from zakkr@zf.jcu.cz)
186
+ Received: from localhost (zakkr@localhost)
187
+ by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id JAA20862;
188
+ Mon, 6 Nov 2000 09:15:04 +0100
189
+ Date: Mon, 6 Nov 2000 09:15:04 +0100 (CET)
190
+ From: Karel Zak <zakkr@zf.jcu.cz>
191
+ To: Christof Petig <christof.petig@wtal.de>
192
+ cc: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
193
+ The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgresql.org
194
+ Subject: Re: AW: [HACKERS] Re: [GENERAL] Query caching
195
+ In-Reply-To: <3A02DDFF.E8CBFCF3@wtal.de>
196
+ Message-ID: <Pine.LNX.3.96.1001106090801.20612C-100000@ara.zf.jcu.cz>
197
+ MIME-Version: 1.0
198
+ Content-Type: TEXT/PLAIN; charset=US-ASCII
199
+ Precedence: bulk
200
+ Sender: pgsql-hackers-owner@postgresql.org
201
+ Status: OR
202
+
203
+
204
+ On Fri, 3 Nov 2000, Christof Petig wrote:
205
+
206
+ > Karel Zak wrote:
207
+ >
208
+ > > On Thu, 2 Nov 2000, Zeugswetter Andreas SB wrote:
209
+ > >
210
+ > > >
211
+ > > > > Well I can re-write and resubmit this patch. Add it as a
212
+ > > > > compile time option
213
+ > > > > is not bad idea. Second possibility is distribute it as patch
214
+ > > > > in the contrib
215
+ > > > > tree. And if it until not good tested not dirty with this main tree...
216
+ > > > >
217
+ > > > > Ok, I next week prepare it...
218
+ > > >
219
+ > > > One thing that worries me though is, that it extends the sql language,
220
+ > > > and there has been no discussion about the chosen syntax.
221
+ > > >
222
+ > > > Imho the standard embedded SQL syntax (prepare ...) could be a
223
+ > > > starting point.
224
+ > >
225
+ > > Yes, you are right... my PREPARE/EXECUTE is not too much ready to SQL92,
226
+ > > I some old letter I speculate about "SAVE/EXECUTE PLAN" instead
227
+ > > PREPARE/EXECUTE. But don't forget, it will *experimental* patch... we can
228
+ > > change it in future ..etc.
229
+ > >
230
+ > > Karel
231
+ >
232
+ > [Sorry, I didn't look into your patch, yet.]
233
+
234
+ Please, read my old query cache and PREPARE/EXECUTE description...
235
+
236
+ > What about parameters? Normally you can prepare a statement and execute it
237
+
238
+ We have in PG parameters, see SPI, but now it's used inside backend only
239
+ and not exist statement that allows to use this feature in be<->fe.
240
+
241
+ > using different parameters. AFAIK postgres' frontend-backend protocol is not
242
+ > designed to take parameters for statements (e.g. like result presents
243
+ > results). A very long road to go.
244
+ > By the way, I'm somewhat interested in getting this feature in. Perhaps it
245
+ > should be part of a protocol redesign (e.g. binary parameters/results).
246
+ > Handling endianness is one aspect, floats are harder (but float->ascii->float
247
+ > sometimes fails as well).
248
+
249
+ PREPARE <name> AS <query>
250
+ [ USING type, ... typeN ]
251
+ [ NOSHARE | SHARE | GLOBAL ]
252
+
253
+ EXECUTE <name>
254
+ [ INTO [ TEMPORARY | TEMP ] [ TABLE ] new_table ]
255
+ [ USING val, ... valN ]
256
+ [ NOSHARE | SHARE | GLOBAL ]
257
+
258
+ DEALLOCATE PREPARE
259
+ [ <name> [ NOSHARE | SHARE | GLOBAL ]]
260
+ [ ALL | ALL INTERNAL ]
261
+
262
+
263
+ An example:
264
+
265
+
266
+ PREPARE chris_query AS SELECT * FROM pg_class WHERE relname = $1 USING text;
267
+
268
+ EXECUTE chris_query USING 'pg_shadow';
269
+
270
+
271
+ Or mean you something other?
272
+ Karel
273
+
274
+
275
+
276
+
277
+
278
+
279
+ From pgsql-hackers-owner+M444@postgresql.org Thu Nov 9 03:32:10 2000
280
+ Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
281
+ by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id DAA09953
282
+ for <pgman@candle.pha.pa.us>; Thu, 9 Nov 2000 03:32:09 -0500 (EST)
283
+ Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
284
+ by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eA98RSs11426;
285
+ Thu, 9 Nov 2000 03:27:28 -0500 (EST)
286
+ (envelope-from pgsql-hackers-owner+M444@postgresql.org)
287
+ Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4])
288
+ by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eA98OPs11045;
289
+ Thu, 9 Nov 2000 03:24:25 -0500 (EST)
290
+ (envelope-from zakkr@zf.jcu.cz)
291
+ Received: from localhost (zakkr@localhost)
292
+ by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id JAA08951;
293
+ Thu, 9 Nov 2000 09:23:41 +0100
294
+ Date: Thu, 9 Nov 2000 09:23:41 +0100 (CET)
295
+ From: Karel Zak <zakkr@zf.jcu.cz>
296
+ To: Christof Petig <christof.petig@wtal.de>
297
+ cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
298
+ Michael Meskes <meskes@postgresql.org>,
299
+ Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
300
+ The Hermit Hacker <scrappy@hub.org>
301
+ Subject: Re: AW: [HACKERS] Re: [GENERAL] Query caching
302
+ In-Reply-To: <3A096BCE.F9887955@wtal.de>
303
+ Message-ID: <Pine.LNX.3.96.1001109090739.8052B-100000@ara.zf.jcu.cz>
304
+ MIME-Version: 1.0
305
+ Content-Type: TEXT/PLAIN; charset=US-ASCII
306
+ Precedence: bulk
307
+ Sender: pgsql-hackers-owner@postgresql.org
308
+ Status: OR
309
+
310
+
311
+ On Wed, 8 Nov 2000, Christof Petig wrote:
312
+
313
+ > Karel Zak wrote:
314
+ >
315
+ > > > What about parameters? Normally you can prepare a statement and execute it
316
+ > >
317
+ > > We have in PG parameters, see SPI, but now it's used inside backend only
318
+ > > and not exist statement that allows to use this feature in be<->fe.
319
+ >
320
+ > Sad. Since ecpg would certainly benefit from this.
321
+ >
322
+ > > > using different parameters. AFAIK postgres' frontend-backend protocol is not
323
+ > > > designed to take parameters for statements (e.g. like result presents
324
+ > > > results). A very long road to go.
325
+ > > > By the way, I'm somewhat interested in getting this feature in. Perhaps it
326
+ > > > should be part of a protocol redesign (e.g. binary parameters/results).
327
+ > > > Handling endianness is one aspect, floats are harder (but float->ascii->float
328
+ > > > sometimes fails as well).
329
+ > >
330
+ > > PREPARE <name> AS <query>
331
+ > > [ USING type, ... typeN ]
332
+ > > [ NOSHARE | SHARE | GLOBAL ]
333
+ > >
334
+ > > EXECUTE <name>
335
+ > > [ INTO [ TEMPORARY | TEMP ] [ TABLE ] new_table ]
336
+ > > [ USING val, ... valN ]
337
+ > > [ NOSHARE | SHARE | GLOBAL ]
338
+ > >
339
+ > > DEALLOCATE PREPARE
340
+ > > [ <name> [ NOSHARE | SHARE | GLOBAL ]]
341
+ > > [ ALL | ALL INTERNAL ]
342
+ > >
343
+ > > An example:
344
+ > >
345
+ > > PREPARE chris_query AS SELECT * FROM pg_class WHERE relname = $1 USING text;
346
+ >
347
+ > I would prefer '?' as a parameter name, since this is in the embedded sql standard
348
+ > (do you have a copy of the 94 draft? I can mail mine to you?)
349
+
350
+ This not depend on query cache. The '$n' is PostgreSQL query parametr
351
+ keyword and is defined in standard parser. The PREPARE statement not parsing
352
+ query it's job for standard parser.
353
+
354
+ > Also the standard says a whole lot about guessing the parameter's type.
355
+ >
356
+ > Also I vote for ?::type or type(?) or sql's cast(...) (don't know it's syntax)
357
+ > instead of abusing the using keyword.
358
+
359
+ The postgresql executor expect types of parametrs in separate input (array).
360
+ I not sure how much expensive/executable is survey it from query.
361
+
362
+ > > EXECUTE chris_query USING 'pg_shadow';
363
+ >
364
+ > Great idea of yours to implement this! Since I was thinking about implementing a
365
+ > more decent schema for ecpg but had no mind to touch the backend and be-fe
366
+ > protocol (yet).
367
+ > It would be desirable to do an 'execute immediate using', since using input
368
+ > parameters would take a lot of code away from ecpg.
369
+
370
+ By the way, PREPARE/EXECUTE is face only. More interesting in this period is
371
+ query-cache-kernel. SQL92 is really a little unlike my PREPARE/EXECUTE.
372
+
373
+ Karel
374
+
375
+
0 commit comments