Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 32757 invoked from network); 16 Dec 2006 00:32:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Dec 2006 00:32:43 -0000 Received: (qmail 75504 invoked by uid 500); 16 Dec 2006 00:32:51 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 75272 invoked by uid 500); 16 Dec 2006 00:32:50 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 75262 invoked by uid 99); 16 Dec 2006 00:32:50 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Dec 2006 16:32:50 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Dec 2006 16:32:42 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7751271413F for ; Fri, 15 Dec 2006 16:32:22 -0800 (PST) Message-ID: <17284132.1166229142486.JavaMail.jira@brutus> Date: Fri, 15 Dec 2006 16:32:22 -0800 (PST) From: "A B (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-2152) Support diagnostic vti tables that take parameters, such as SpaceTable In-Reply-To: <30249954.1165345341004.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ http://issues.apache.org/jira/browse/DERBY-2152?page=comments#action_12458980 ] A B commented on DERBY-2152: ---------------------------- > I guess I'd thought about having separate resolution for the two different types, > tables that map to vtis and table functions that map to vtis. Hmm...okay, I'll have to ponder this a bit to see if this separation is a better approach. I'm not quite clear on what exactly that means just yet... > From looking at the patch I now see that the SYSCS_DIAG is not part of the > syntax grammar, but matches the existing use for the diagnostic tables. Right, I think my Jira comments were misleading in that regard (sorry). But this did prompt me to push the relevant code further down into DataDictionary, which I think makes things a bit cleaner. So I'll include those changes in subsequent patches. I'll wait another day or so before posting a followup patch (probably on Monday or Tuesday) in case there is more discussion re: the other issues I mentioned in my previous comment. Thank you for the quick feedback! > Support diagnostic vti tables that take parameters, such as SpaceTable > ---------------------------------------------------------------------- > > Key: DERBY-2152 > URL: http://issues.apache.org/jira/browse/DERBY-2152 > Project: Derby > Issue Type: Improvement > Components: SQL > Reporter: Daniel John Debrunner > Assigned To: A B > Attachments: d2152_engine_v1.patch, d2152_testing_v1.patch, d2152_v1.stat > > > Expand the work of DERBY-571 to support the remaining diagnostic tables that take parameters. > Syntax would use the table constructor, like (not sure if an 'AS' clause will be required: > select * from TABLE(SYSCS_DIAG.SPACE_TABLE(?, ?)) > Diagnostic VTIs that could be handled this way are: > ErrorLogReader(String log file name) > SpaceTable(String tableName) > SpaceTable(String schemaName, String tableName) > StatementDuration(String inputFileName) > This is the second stage mentioned in DERBY-571 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira