Subject | Re: [Firebird-Architect] Sending very very long statements |
---|---|
Author | Martijn Tonies |
Post date | 2007-08-05T19:06:11Z |
> Martijn Tonies wrote:well.
> >> There a gobs of 64K restrictions in the server. All are historical and
> >> can be eliminated, but BLR would have to be extended for 4 byte counts
> >> and lengths for openers, and couple of other dozen things fixed as
> >>Local file? On the client? Yes, nice, but not SQL standard.
> >> It would be smarter to find out why such ludicrous statements are being
> >> used and extend SQL to make them unnecessary.
> >>
> >
> > In order to be able to send blobs directly from a script.
> >
> >
> >>> Would this make sense? I understand this is a change in the
> >>> wire protocol, but it would finally get Firebird up to date with
> >>> regard to sending BLOBs to the server like the SQL Standard
> >>> specifies.
> >>>
> >>>
> >>>
> >> Somehow I think the SQL standard is silent about how blobs are
> >> communicated between a client and the server. I agree that it would be
> >> nice to allow arbitrary conversion between various types and blobs
> >> (almost everyone else has them), but I don't think any change is
> >> necessary to the wire protocol to support them.
> >>
> >
> > Indeed, the SQL Standard says nothing abuot communication -- what
> > I meant was that the standard allows to send (binary) blobs to the
> > server from a script by using a special syntax:
> >
> > insert into mytable (myblob)
> > values X'0101002200448AE884E0232...
> >
> Why would a script be sending a large blob literal? Might it not make
> more sense to be able to reference a local file name in a script rather
> than translate the content into hex?
But with this functionality, you can also store blobs that are not files.
> > But given that Firebird doesn't support long SQL statements, it canSee above, blobs don't have to be files to begin with.
> > never create this is a useful manner.
> >
> Don't think of the problem as "long sql statements" -- that's a
> statement of a work around, not a solution. It would be better to go
> back to the original problem, state it clearly, and think about the
> range of alternative solutions. Jpegs, for example, are never born as
> ascii representations of hex digits. There's gotta a better way than
> that...
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com