Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > We would have to reconsider *alter table .. rename ..* ..
>
> Yeah, that's one thing that would act differently if we adopt my idea of
> considering the source text of the rule to be the primary definition.
> It's not clear if this
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> We would have to reconsider *alter table .. rename ..* ..
Yeah, that's one thing that would act differently if we adopt my idea of
considering the source text of the rule to be the primary definition.
It's not clear if this is good or bad, however. Con
Tom Lane wrote:
>
> Jan Wieck <[EMAIL PROTECTED]> writes:
>
> What everyone else is telling you is that we should strive to do the
> same, not punt and make the user tell us when to recompile.
>
In Oracle, objects like views, functions and triggers are
just marked INVALID when an object to whic
IMHO we are trying to have a compiled language behave like an interpreted
language.
This is a bottom to top approach with no real future. Here is a proposal of
a top to bottom approach.
What we do in pgAdmin is that we store objects (functions, views and
triggers) in separate tables called Dev
Jan Wieck <[EMAIL PROTECTED]> writes:
> You cannot control Tcl's bytecode compiler from the outside.
An excellent example. You don't *need* to control Tcl's bytecode
compiler from the outside, because *Tcl gets it right without help*.
It takes care of the function-text-to-derived-form depen
On Thu, 12 Jul 2001, Jan Wieck wrote:
> Alex Pilosov wrote:
> > I remember awhile ago, someone floated the idea of a dependency view which
> > would list all objects and what OIDs they have in their plan. (i.e. what
> > do they depend on).
> >
> > I'm definitely no expert in this, but to me, one
Jan Wieck <[EMAIL PROTECTED]> writes:
> For most objects, there is no such "recompile" possible - at
> least not without storing alot more information than now.
> Create a function and based on that an operator. Then you
> drop the function and create another one. Hmmm,
Jan Wieck writes:
> For most objects, there is no such "recompile" possible - at
> least not without storing alot more information than now.
> Create a function and based on that an operator. Then you
> drop the function and create another one. Hmmm, pg_operator
> d
Jan Wieck <[EMAIL PROTECTED]> writes:
> Stop!
> We're talking about two different things here.
You're right: fixing obsoleted querytrees stored in pg_rewrite and
similar catalogs is not the same thing as invalidating cached
query plans in plpgsql, SPI, etc.
However, we could turn them in
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>
> > In the PL/pgSQL case it *might* be possible. But is it worth
> > it?
>
> Yes. If we're not going to do it right, I think we needn't bother to do
> it at all. "Restart your backend" is just as good an answer, probably
> better
On Thu, 12 Jul 2001, Peter Eisentraut wrote:
> Jan Wieck writes:
>
> > For most objects, there is no such "recompile" possible - at
> > least not without storing alot more information than now.
> > Create a function and based on that an operator. Then you
> > drop the
Jan Wieck <[EMAIL PROTECTED]> writes:
> There is of course a difference between the original
> CREATE RULE/VIEW statement and the string stored here. This
> is because we cannot rely on the actual query buffer but have
> to parseback the parsetree like done by the utility functio
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > This isn't local recompilation in current backend. It's
> > recreation of the pg_rewrite entry for a relation, including
> > propagation.
>
> Where I'd like to go (see my previous mail) is that pg_rewrite,
> pg_attrdef,
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > There is of course a difference between the original
> > CREATE RULE/VIEW statement and the string stored here. This
> > is because we cannot rely on the actual query buffer but have
> > to parseback the parsetree like d
Jan Wieck <[EMAIL PROTECTED]> writes:
> This isn't local recompilation in current backend. It's
> recreation of the pg_rewrite entry for a relation, including
> propagation.
Where I'd like to go (see my previous mail) is that pg_rewrite,
pg_attrdef, and friends store *only* the
Jan Wieck <[EMAIL PROTECTED]> writes:
> And PL/pgSQL? We don't prepare all the statements into SPI
> plans at compile time. We wait until the separate branches
> are needed, so how do you know offhand here?
If we haven't prepared a statement yet, then we don't need to reprepare
Jan Wieck <[EMAIL PROTECTED]> writes:
> are you sure that this doesn't have a severe performance
> impact?
It's not provable, of course, until we try it ... but I think the
performance impact would be small. Has anyone complained about the
fact that plpgsql functions are stored as s
Mikheev, Vadim wrote:
> > > Why is it possible in Oracle' world? -:)
> >
> > Because of there limited features?
>
> And now we limit our additional advanced features -:)
>
> > Think about a language like PL/Tcl. At the time you call a
> > script for execution, you cannot even be sur
Alex Pilosov wrote:
> I remember awhile ago, someone floated the idea of a dependency view which
> would list all objects and what OIDs they have in their plan. (i.e. what
> do they depend on).
>
> I'm definitely no expert in this, but to me, one possible implementation
> would be to enhance outfu
> > Why is it possible in Oracle' world? -:)
>
> Because of there limited features?
And now we limit our additional advanced features -:)
> Think about a language like PL/Tcl. At the time you call a
> script for execution, you cannot even be sure that the Tcl
> bytecode c
On Thu, 12 Jul 2001, Jan Wieck wrote:
> Mikheev, Vadim wrote:
> > > > In good world rules (PL functions etc) should be automatically
> > > > marked as dirty (ie recompilation required) whenever referenced
> > > > objects are changed.
> > >
> > > Yepp, and it'd be possible for rules (just n
I remember awhile ago, someone floated the idea of a dependency view which
would list all objects and what OIDs they have in their plan. (i.e. what
do they depend on).
I'm definitely no expert in this, but to me, one possible implementation
would be to enhance outfuncs to provide for creation tr
> > In good world rules (PL functions etc) should be automatically
> > marked as dirty (ie recompilation required) whenever referenced
> > objects are changed.
>
> Yepp, and it'd be possible for rules (just not right now).
> But we're not in a really good world, so it'll not be
Mikheev, Vadim wrote:
> > Anyway, what's the preferred syntax for triggering the rule
> > recompilation? I thought about
> >
> > ALTER RULE {rulename|ALL} RECOMPILE;
> >
> > Where ALL triggers only those rules where the user actually
> > has RULE access right on a rela
Mikheev, Vadim wrote:
> > > In good world rules (PL functions etc) should be automatically
> > > marked as dirty (ie recompilation required) whenever referenced
> > > objects are changed.
> >
> > Yepp, and it'd be possible for rules (just not right now).
> > But we're not in a really
> Anyway, what's the preferred syntax for triggering the rule
> recompilation? I thought about
>
> ALTER RULE {rulename|ALL} RECOMPILE;
>
> Where ALL triggers only those rules where the user actually
> has RULE access right on a relation.
In good world rules (PL fun
26 matches
Mail list logo
