In article <024401c4aac0$c7ae53f0$0a02a8c0@martijn>,
"Martijn Tonies" <m.tonies@stripped> writes:
> Hello Harald, others,
>> > This is plain rubbish. See my other example with a more complicated
>> > view source. When adjusting the view, or extracting a script - the
>> > view source becomes complete gibberish.
>> > MS SQL, or Firebird, for example, store the view-source as defined -
>> > this includes comments, spacing etc etc... In short: it becomes usuable.
>> > MySQL should do this too. From reading these lists, I think MySQL
>> > only stores the resulting structure - or something similar - and
>> > (currently) not the view source. To make views useful, better change
>> > it... :-)
>> Nope. A standards-compliant database is _required_ to store the
>> structure of its objects in its internal information_schema, not some
>> SQL string. Of course MySQL isn't standards-compliant at all, but we
>> should not make it worse by imitating the quirks of other DBMSs.
> I'm unsure what to make of this statement --
> I was asking if the view-source can be stored, so that it can be retrieved
> the way I created it. Do you agree or disagree?
I disagree. A proper information_schema implementation is much more
than a stored SQL string - it's a standardized way to access meta
information about your DB objects. Thus it must parse the SQL DDL
strings and store its "meaning". Additionally storing the SQL string
_as entered_ would be redundancy.
SHOW CREATE VIEW could be implemented by reconstructing some standard
representation of SQL DDL, but this would not always be exactly what
On the other hand, omitting superfluous backticks (double quotes in
standard SQL) from the output sounds reasonable.