At 05:05 PM 2/03/2005 +0000, Alexei Isac wrote:

>What is the reccomended way to define datatypes for the IN an OUT
>parameters in scripts ? My script is getting a little too big and I
>was wondering if there is an alternate way to define the VARCHAR(N)
>once for the various IN params in PSQL scrpits, that way if the
>lengths need to be increased, I need to do it only in one place.

No. Each PSQL module is compiled in its own context. That includes memory
management for string variables, of course.

That doesn't mean I oppose the idea of user-defined subtypes for strings -
I think it would be a great leap forward. The engine currently does some
pretty (IMHO) ugly and roundabaout things to manage allocation and
deallocation for strings, that is being rigorously addressed in the
discussions around the development of Fb 2, Vulcan and Fb 3. So the short
answer is, the engine should be expected to become more receptive to
special needs regarding string types.

>ps: Btw, excellent work on the book, I love it. Got me upto speed very
>quick. If I may say so, In the next edition, I would like to see a
>little more on the new embedded server, which I think is a killer
>compared to Sqlite and Berkley DB.

Architecturally, the Windows embedded server isn't different to Windows
Superserver - it's the same engine and the same client. OTOH, the network
transport for Win embedded has been redone in Firebird 2 and, in my mind,
the embedded model on Win32 has become a lot more robust in Fb2. Space
permitting, it could be worthwhile to concentrate all of the Win32 embedded
stuff into one chapter in the second edition.

With this particular publisher, space between the covers is an issue that
often had to override common sense and good book design. This publisher
has one single book template which it refuses to vary. For an author, the
template is wasteful and restrictive to work with. For readers, it seems
quite confusing to use. There are a lot of things I would have done
differently without these limitations.

It is something I have to put under serious consideration before accepting
a contract with the same publisher for 2E. Simply, 2E has to take in not
just Fb 1 and 1.5 but also Fb 2 and Vulcan. The book already exceeded the
Apress limits on book size by about 30%. I *like* that they made the
binding of the big book strong enough to resist disintegrating with
frequent use; I respect and appreciate their willingness to DO our
book; but I can't work with their template for the 2E without making a
book with a lot more pages. A problem. Other publishers have much more
workable book formats but they haven't asked to publish the 2E.

./hb