The right URL (I'll get it eventually) is
ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-02-Foundation-2002-01.pdf
That time I exactly copied the URL. sorry for the wrong one previously.
On 20 Feb 2003, Dave Cramer wrote:
> Scott,
>
> Thanks for the reference, I think the actual document is
>
> ftp://ftp.sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-01-Framework-2002-01.pdf
>
> and it is in section 14.12
>
>
> on or about page 839
>
> Dave
> On Thu, 2003-02-20 at 11:20, scott.marlowe wrote:
> > On Thu, 20 Feb 2003, Tom Lane wrote:
> >
> > > Hannu Krosing <hannu@tm.ee> writes:
> > > > Are you against it just on grounds of cleanliness and ANSI compliance,
> > > > or do you see more serious problems in letting it in ?
> > >
> > > At this point it seems there are two different things being tossed
> > > about. I originally understood Dave to be asking for parens to be
> > > allowed around individual target column names, which seems a useless
> > > frammish to me. What Bruce has pointed out is that a syntax that lets
> > > you assign multiple columns from a single rowsource would be an actual
> > > improvement in functionality, or at least in convenience and efficiency.
> > > (It would also be a substantial bit of work, which is why I think this
> > > isn't what Dave was offering a quick patch to do...) What I'd like to
> > > know right now is which interpretation Informix actually implements.
> > >
> > > I don't like adding nonstandard syntaxes that add no functionality ---
> > > but if Informix has done what Bruce is talking about, that's a different
> > > matter altogether.
> >
> > Tom, I was purusing the wild and wonderfully exciting new SQL
> >
> > (found here:
> > ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-01-Framework-2002-01.pdf)
> >
> > ANSI TC NCITS H2
> > ISO/IEC JTC 1/SC 32/WG 3
> > Database
> >
> > document to see what it had to say, and on this subject, and it looks like
> > update is going to be supporing this same style we're discussing here.
> >
> > Look on or around p. 858 in that doc.)
>