FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> > 
> > If nobody complaints I'll merge this work in a couple of days...
> 
> Hi Freddy, 
> 
> I have a few concerns about this patch.  
> 
> First, things are pretty stable and I'm thinking of making a 
> release.  I'd
> rather not make such fundamental changes at this point.  
> Could we agree on
> a release schedule and postpone until we branch?  
> 

Yes, no problem

> Second, I know you love DSTR but I don't.  I think they're 
> harder to debug
> than ordinary char*.  I'm not that happy with using them in 
> the TDS layer.
>  
> 
> Third, I don't think we should change column_name to column_label
> everywhere just because there are a few odd cases where the protocol
> distinguishes.  Most of the time the label *is* the name for 
> all intents
> and purposes.  And, everyone knows what a column name is: 
> it's the name of
> the column.  Calling it a  "label" is nonstandard and 
> somewhat confusing. 
> 

Agree... the same confusion raise from protocol documentation... they use 
"column label" when a table column name is available but they use "column 
name" when only the label is available...

> 
> I think it would be better to retain column_name for normal 
> use, and have
> a different name, say, underlying_name or table_column_name  
> to denote the
> name of the table's column.   (Honestly, I doubt the value of 
> knowing the
> information in the first place....)
> 

Yes, this is feasible and definitely less invasive... now... how should we 
declare this table_column_name?? DSTR, char* or a normal array (like 
column_name) ??
This information is important for cursors and for browse clause. If you have 
a query like "select a.x as y, b.z as k from a inner join b on a.a = b.b" and 
you want to update column "k" you have to know that "k" is column "z" of 
table "b"... yes it's complicated, rarely used but in theory should work. 
This is the way to implement correctly functions like dbcolsource.

freddy77