Subject | Re: [ib-support] Idea for a new field type for FB 2,0 or IB 7? |
---|---|
Author | Jason Wharton |
Post date | 2001-11-22T02:07:12Z |
"Returning" is already a feature of BLR that just needs to be "plumbed" via
SQL in the BLR-to-DSQL layer. It already is in the engine. Charlie Caro told
me how it works. Perhaps you missed that part of my post. I agree entirely
this is where such a feature belongs. In fact, it would be impossible to
implement this feature anywhere but in the engine.
What I said should be external is the little tool that would generate and
maintain all the generator and trigger creation. I wouldn't complain so much
about adding the whole lot to the engine as long as the RETURNING capability
were done as an integral part of the overall strategy and if it were also
done in the trigger/stored procedure language. There is no use for an
auto-inc field type in a client/server system unless the client can be
informed of what the values were set to upon insert. The reason I wouldn't
mind so much is because there is already a lot of system generator and
trigger stuff going on. What I would object to is putting in all sorts of
"smarty-pants" stuff like automatically detecting PK violations and
automatically setting itself to the highest value based on existing data in
the table. In short, lets not bloat the engine with anything that can best
be done externally.
And, while people are at it, I want the ability to:
EXECUTE PROCEDURE some_proc ( acol, acol, acol, ... )
SELECT ( acol, acol, acol, ... )
just like you can do with an Insert statement. This should also just be a
simple addition to parsing. BLR should already support this type of
operation as well. I wonder if GDML had anything similar to this, I would
bet it does.
Thus, it would take all records from the select and pump them into the
stored procedure.
FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
"Nando Dessena" <nandod@...> wrote in message
news:3BFBF333.74CA7550@......
SQL in the BLR-to-DSQL layer. It already is in the engine. Charlie Caro told
me how it works. Perhaps you missed that part of my post. I agree entirely
this is where such a feature belongs. In fact, it would be impossible to
implement this feature anywhere but in the engine.
What I said should be external is the little tool that would generate and
maintain all the generator and trigger creation. I wouldn't complain so much
about adding the whole lot to the engine as long as the RETURNING capability
were done as an integral part of the overall strategy and if it were also
done in the trigger/stored procedure language. There is no use for an
auto-inc field type in a client/server system unless the client can be
informed of what the values were set to upon insert. The reason I wouldn't
mind so much is because there is already a lot of system generator and
trigger stuff going on. What I would object to is putting in all sorts of
"smarty-pants" stuff like automatically detecting PK violations and
automatically setting itself to the highest value based on existing data in
the table. In short, lets not bloat the engine with anything that can best
be done externally.
And, while people are at it, I want the ability to:
EXECUTE PROCEDURE some_proc ( acol, acol, acol, ... )
SELECT ( acol, acol, acol, ... )
just like you can do with an Insert statement. This should also just be a
simple addition to parsing. BLR should already support this type of
operation as well. I wonder if GDML had anything similar to this, I would
bet it does.
Thus, it would take all records from the select and pump them into the
stored procedure.
FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
"Nando Dessena" <nandod@...> wrote in message
news:3BFBF333.74CA7550@......
> Jason,
>
> > What I would prefer to see is someone make a little utility which is
> > external to the engine that people, according to their own options and
> > requirements, would use to manage such things.
>
> I strongly believe that any efficient implementation of a "returning"
> clause should be at the engine level. So should system triggers to
> auto-generate keys, while I don't feel an urgent need for the latter and
> have dreamt about the former since the first time I used Oracle.
> Ciao
> --
> ____
> _/\/ando
>