DDL_TRIGGER not fire on DDL operator COMMENT ON
---
Key: CORE-4358
URL: http://tracker.firebirdsql.org/browse/CORE-4358
Project: Firebird Core
Issue Type: Improvement
Affects Versions: 3.0
People, what's the opinion on exceptions that use isc_ramdom to send
hardcoded messages?
Should we use isc_random for most of the future messages or should we
register more text in the messages db and lower the number of hardcoded
messages?
Being realistic, apparently nobody has bothered to create
04.03.2014 21:30, Claudio Valderrama C. wrote:
People, what's the opinion on exceptions that use isc_ramdom to send
hardcoded messages?
IMHO, it is a bad idea. Not because of localized messages, but it makes
status vector
analyzing in programs harder. You are going to look for a definite
On 4-3-2014 21:30, Claudio Valderrama C. wrote:
People, what's the opinion on exceptions that use isc_ramdom to send
hardcoded messages?
Should we use isc_random for most of the future messages or should we
register more text in the messages db and lower the number of hardcoded
messages?
Hi!
Only at Plugin.h, we have two case conventions for constants.
PluginType constants uses a convention I don't remember to see before,
example: FirstNonLibPlugin.
DirType uses ALL_CAPS style.
Also one starts in 1 and another starts in 0.
And if we go to Provider.h IStatement, specific
Accordingly to how new API works, where one can get a version and the
virtual table is filled with possible non-existent methods, classes like
TraceParamsImpl could not insert new virtual functions.
Adriano
--
On 03/05/2014 05:46 AM, Adriano dos Santos Fernandes wrote:
Hi!
Only at Plugin.h, we have two case conventions for constants.
PluginType constants uses a convention I don't remember to see before,
example: FirstNonLibPlugin.
That definitely requires cleanup.
DirType uses ALL_CAPS style.
On 03/05/2014 05:55 AM, Adriano dos Santos Fernandes wrote:
Accordingly to how new API works, where one can get a version and the
virtual table is filled with possible non-existent methods, classes like
TraceParamsImpl could not insert new virtual functions.
Yes, and it was clear since the
On 03/05/2014 12:30 AM, Claudio Valderrama C. wrote:
People, what's the opinion on exceptions that use isc_ramdom to send
hardcoded messages?
Should we use isc_random for most of the future messages or should we
register more text in the messages db and lower the number of hardcoded
messages?