title: Union tables with different schema
body: <p>I am referring to Jordan's answer regarding "dealing with evolving schemas "<a href="https://stackoverflow.com/questions/18609114/dealing-with-evolving-schemas">Dealing with evolving schemas</a>.</p>
  
  <p>As I share similar problem I have tried to query tables with different schema and got the following results:</p>
  
  <pre><code>Select a,b,c 
  FROM (Select 1 as a, 2 as b), --Test_a
       (Select 1 as a, 2 as b, 3 as c), --Test_b
  </code></pre>
  
  <p>runs fine...
  I have put Test_a and Test_b into physical tables (all fields are nullable) and tried:</p>
  
  <pre><code> Select a,b,c 
   FROM (Select a,b, from BI_WORKSPACE.Test_a), 
        (Select a,b,c from BI_WORKSPACE.Test_b)
  </code></pre>
  
  <p>It also runs fine</p>
  
  <p>but when i tried </p>
  
  <pre><code> Select a,b,c 
  FROM BI_WORKSPACE.Test_a,
       BI_WORKSPACE.Test_b 
  </code></pre>
  
  <p>It failed...
  Is there a bug, something i do wrong?
  the last sample is the one i am after as it allows me to "evolve" my schema over time. i would like to avoid altering schema of all existing tables whenever i add a column to support a new business need.</p>
  
  <p>Many thanks for your help.</p>
  
  <p>The reason for asking:
  We hold our data in "Daily tables" so when querying we pay only for the period we are interested in.
  As BQ doesn’t support "Dynamic SQL", we have created an offline process that takes a query template and generates a query for desired period. Something like:
  Input: </p>
  
  <pre><code>Select a,b,c FROM [&lt;Source&gt;] 
  </code></pre>
  
  <p>Output: </p>
  
  <pre><code>Select a,b,c FROM [MYDATASET.TABLE20140201], [MYDATASET.TABLE20140202], [MYDATASET.TABLE20140203], [MYDATASET.TABLE20140204] , [MYDATASET.TABLE20140205] , [MYDATASET.TABLE20140206] , [MYDATASET.TABLE20140207]
  </code></pre>
  
  <p>Our process is unaware of the query logic. Sometimes we add fields to support evolving business needs. 
  Using dynamic sub selects will complicate staff a lot, and altering the schema for all hundreds of existing tables is expensive and prone to mistakes.
  Any suggestions?</p>