>
> I am not part of the dev team, but I think that removing the 64kb limit
> would be something pretty annoying to do (change dataypes all over),
> manage internal structures to handle that new size, etc. It could be
> potentially dangerous, since once one place was forgotten would be a
> mess... I think it's something like increasing the object names size, a
> desired feature, but not top priority (IMHO greater objects names would
> be very well received). In fact, if I a major revamp would be made on
> internal system tables I would propouse to use ObjectID's instead of
> names to reference and create dependencies, etc. The major problem I
> see
> with those changes is that would break backward compatibility, but it
> could be solved creating views that mimics the old system tables, and
> the new ones would be created with new names fb$something, the major
> diferences would be hiden by the views.
>
> Increase the IN limit, would be better than have it as it is now but
> always there is work arounds as you, me and others said, so it's very
> low priority IMHO.
>

Agreed.
Increasing the "in" limit would be a major job. Implementing and testing would probably be a nightmare, and in my opinion, not worth it at all, especially since there is no real reason for such changes. "In" is simply not the right solution for the problem in question.

As for 31 char for object names, I also agree that would probably be welcomed change. I have been in situations where I needed a few extra characters. But like I said, there is so much good work being done in firebird project, that I'll gladly accept the limit and leave the developers to continue working on really important stuff.

Sasha