<div dir="ltr">Hi Walter, all,<br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-09 18:46 GMT+02:00 Walter Landry <span dir="ltr">&lt;<a href="mailto:wlandry@caltech.edu" target="_blank">wlandry@caltech.edu</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Everyone,<br>
<br>
Looking at the list of VOTable FIELD attributes<br>
<br>
  <a href="http://www.ivoa.net/documents/VOTable/20130920/REC-VOTable-1.3-20130920.html#ToC25" rel="noreferrer" target="_blank">http://www.ivoa.net/documents/<wbr>VOTable/20130920/REC-VOTable-<wbr>1.3-20130920.html#ToC25</a><br>
<br>
they mostly map straight to columns in TAP_SCHEMA.columns.  Two<br>
significant exceptions are width and precision.  Maybe we should add<br>
those?  We can always get it by doing a null query, but it seems like<br>
something that should be in TAP_SCHEMA.columns.<br></blockquote><div><br></div><div>While trying to have a unique datatype system for the VO </div><div>is the reason why types in TAP_SCHEMA and ADQL are</div><div>being aligned to VOTable, I don&#39; think that all of the</div><div>VOTable features for FIELDS and PARAMs should go into</div><div>TAP_SCHEMA.</div><div><br></div><div>So, for me, width and precision are optional worthy</div><div>parameters to a VOTable response, but are not</div><div>exactly what a TAP_SCHEMA should hold.</div><div><br></div><div>That said, no one will block custom columns in a</div><div>TAP_SCHEMA, and also, if you have a use case</div><div>that uses those attributes, please implement them</div><div>and show what the benefits are.</div><div><br></div><div>Cheers,</div><div>    Marco</div></div></div></div>