Hello Adriano, >>>> It would need two columns, one for procedure and another for function. >>>> Seems awful. >> Adding a "child object type" column? >> > >But then RDB$FIELD_NAME would be different from it.
Agreed. >RDB$FIELD_NAME is a child object as packaged procedures and functions are. Also agreed, and as a child object, the NAME column has the "parent object". >The exception is that fields are the only single type of child object >(tracked) in a table. > >RDB$DEPENDENCIES was not future-proof designed for children objects. You could use FIELD_NAME, for backwards compatibility, but also add a "child object type" column, for the package extension to distinguish between functions/procedures/future items. Mind you, a computed field has a different object type number of as well, compared to a normal field (3 vs 9). Suddenly, rdb$dependent_name holds the field name, not the table name. To check for dependencies on these, I have to run a separate query already. With regards, Martijn Tonies Upscene Productions http://www.upscene.com Download Database Workbench for Oracle, MS SQL Server, Sybase SQL Anywhere, MySQL, InterBase, NexusDB and Firebird! ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
