Re: Query caching

From: Christof Petig <christof(dot)petig(at)wtal(dot)de>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Meskes <meskes(at)postgresql(dot)org>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, The Hermit Hacker <scrappy(at)hub(dot)org>
Subject: Re: Query caching
Date: 2000-11-10 07:05:38
Message-ID: 3A0B9E42.45B478E6@wtal.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Karel Zak wrote:

> On Wed, 8 Nov 2000, Christof Petig wrote:
>
> > Karel Zak wrote:
> >
> > > > What about parameters? Normally you can prepare a statement and execute it
> > >
> > > We have in PG parameters, see SPI, but now it's used inside backend only
> > > and not exist statement that allows to use this feature in be<->fe.
> >
> > Sad. Since ecpg would certainly benefit from this.

Postponed for future improvements ...

> > > PREPARE chris_query AS SELECT * FROM pg_class WHERE relname = $1 USING text;
> >
> > I would prefer '?' as a parameter name, since this is in the embedded sql standard
> > (do you have a copy of the 94 draft? I can mail mine to you?)
>
> This not depend on query cache. The '$n' is PostgreSQL query parametr
> keyword and is defined in standard parser. The PREPARE statement not parsing
> query it's job for standard parser.

I see.

> > Also the standard says a whole lot about guessing the parameter's type.
> >
> > Also I vote for ?::type or type(?) or sql's cast(...) (don't know it's syntax)
> > instead of abusing the using keyword.
>
> The postgresql executor expect types of parametrs in separate input (array).
> I not sure how much expensive/executable is survey it from query.

That would involve changing the parser. Future project.

> > > EXECUTE chris_query USING 'pg_shadow';
> >
> > Great idea of yours to implement this! Since I was thinking about implementing a
> > more decent schema for ecpg but had no mind to touch the backend and be-fe
> > protocol (yet).
> > It would be desirable to do an 'execute immediate using', since using input
> > parameters would take a lot of code away from ecpg.
>
> By the way, PREPARE/EXECUTE is face only. More interesting in this period is
> query-cache-kernel. SQL92 is really a little unlike my PREPARE/EXECUTE.

I'm looking forward to get first experiences with the query cache kernel. I think it's
the right way to go.

Christof

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2000-11-10 08:36:55 AW: Unhappy thoughts about pg_dump and objects inherite d from template1
Previous Message Tom Lane 2000-11-10 06:21:10 Re: Unhappy thoughts about pg_dump and objects inherited from template1