Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 19 Sep 2005 13:48:50 -0500 Reply-To: "Mark C. Stock" From: "Mark C. Stock" Newsgroups: comp.databases.oracle.server References: <1126705798.012355.18740@g49g2000cwa.googlegroups.com> <1126712247.735544@yasure> <1126716382.588532.161250@g43g2000cwa.googlegroups.com> <1126723858.554220.198110@g43g2000cwa.googlegroups.com> <1126729301.961774.27730@o13g2000cwo.googlegroups.com> <3ot6mnF7lievU1@individual.net> <1126904873.419638.129300@g47g2000cwa.googlegroups.com> <1127152935.283980.15370@g14g2000cwa.googlegroups.com> Subject: Re: Where is a temp tables DDL stored? Date: Mon, 19 Sep 2005 14:48:47 -0400 Organization: Enquery, Incorporated X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Response Message-ID: <8eudnRiOlp6PlbLeRVn-uQ@comcast.com> Lines: 52 NNTP-Posting-Host: 68.57.99.188 X-Trace: sv3-AgbL5LWHjpXSRc6mAu31KyTormkru0Mdm3VAfviMJPDvm4G/+jgW1xJMd4OKXKAeuI2tS/z/EEeyp2D!Vd+Wupzb2stTOZFOqwTW2x6yXAwT0ayRqeCBFGNO/6dkBaygZEamkSpdea9LDInIOpO0fj0SB7wX!xw== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: dp-news.maxwell.syr.edu comp.databases.oracle.server:251826 "Mark C. Stock" wrote in message news:Ze6dncQGd-NUmrLeRVn-iw@comcast.com... > > "Ed Prochak" wrote in message > news:1127152935.283980.15370@g14g2000cwa.googlegroups.com... >> >> mikharakiri_nosp...@yahoo.com wrote: >>> Jonathan Lewis wrote: >>> > Just playing devil's advocate, but why couldn't >>> > the database reverse engineer the corrected >>> > DDL from the data dictionary as the dictionary >>> > is updated ? >>> >>> To extend this idea further, I always wondered why the concept of DDL >>> is needed at all? Consider >>> >>> -- create 100 tables TEST1...TEST100 >>> insert into user_tables -- or, more concervatively, tab$ >>> as select 'TEST'||rownum table_name, ... >>> from dual connect by rownum < 100 >>> >>> insert into user_tab_columns -- or, more concervatively, col$ >>> ... >>> >>> commit; >> >> I'd say its the side-effect issue. With the above approach, you insert >> into one table and Voila a new table exists. >> >> But also note: using that method you can "create" a table with NO >> columns. And what about the other side effects of CREATE TABLE: >> allocating space, granting permissions, etc.? >> >> So direct inserts in the Data dictionary table are not a great idea, >> even if that is what the DBMS does in the background. >> >> ed >> > > just consider DDL to be the data dictionary API -- just parsed instead of > parameterized > > ++ mcs > make that a '(semi-)standardized data dictionary API', since all RDBMS data dictionaries are not structured the same ++ mcs