Kathey Marsden writes:
> After reviewing everyone's input I think that I'd be ok if we go ahead
> with the extension in this particular case, if we have such a
> disclaimer in the documentation. Is this acceptable to all?
+1
Dag
Mike Matrigali wrote:
It would be good to see clear documentation of this feature as a
non-standard
implementation, maybe with some note that if a standard comes in this
area we
may change the behavior to match it.
After reviewing everyone's input I think that I'd be ok if we go ahead
with
On Jul 10, 2009, at 10:47 AM, Kathey Marsden wrote:
Lance Andersen wrote:
3) Does this create a slippery slope for violation of our
standards based charter?
I do not see how. Every database vendor has their own extensions
which are above and beyond standards
Such a liberal approac
Dag H. Wanvik wrote:
I think the mitigating circumstance here is that Rick says that this
is an *omission* on part of the SQL standards committee. Naturally,
they might change the syntax entirely for 2011, or choose *not* to
allow this anyway, but that hardly seems likely. The OFFSET, FETCH
FIRS
Dag H. Wanvik wrote:
Anyway, I'm out for 2 weeks, so this won't make 10.5.2 in any case ;)
I am glad we are not under the gun for this for 10.5.2. Have a great
vacation Dag and Rick!
Kathey
I think the mitigating circumstance here is that Rick says that this
is an *omission* on part of the SQL standards committee. Naturally,
they might change the syntax entirely for 2011, or choose *not* to
allow this anyway, but that hardly seems likely. The OFFSET, FETCH
FIRST/NEXT syntax is now fi
Lance Andersen wrote:
3) Does this create a slippery slope for violation of our standards
based charter?
I do not see how. Every database vendor has their own extensions
which are above and beyond standards
Such a liberal approach to extensions would certainly require a change
to our
On Jul 10, 2009, at 9:12 AM, Kathey Marsden wrote:
Rick Hillegas wrote:
Other forms of parameterization are allowed by the standard. It is
just that ? parameters are not explicitly included. The consensus
of the committee members who discussed this was that this was an
oversight, and no-o
Rick Hillegas wrote:
Other forms of parameterization are allowed by the standard. It is
just that ? parameters are not explicitly included. The consensus of
the committee members who discussed this was that this was an
oversight, and no-one could explain why ? parameters had been omitted.
The
Kathey Marsden wrote:
Rick Hillegas wrote:
I think that this discussion has gotten seriously off-track. It is
the intent of the standard that the offset and window length values
be parameterized. This is clear from the standard language
Hmmm, I thought the problem was that the standard did not
Rick Hillegas wrote:
I think that this discussion has gotten seriously off-track. It is the
intent of the standard that the offset and window length values be
parameterized. This is clear from the standard language and I
confirmed this with the SQL committee in May. For the record, Lance
and
Rick Hillegas wrote:
I think that this discussion has gotten seriously off-track. It is the
intent of the standard that the offset and window length values be
parameterized. This is clear from the standard language
Hmmm, I thought the problem was that the standard did not allow for
parameters a
I think that this discussion has gotten seriously off-track. It is the
intent of the standard that the offset and window length values be
parameterized. This is clear from the standard language and I confirmed
this with the SQL committee in May. For the record, Lance and I sit on
the SQL commit
Kathey Marsden wrote:
Mike Matrigali wrote:
I would rather wait for an approved standard so that we don't later
get caught with apps depending on a non-standard behavior that we
might want to change in the future to meet a standard.
From the provided info it does not even look like there is a
Mike Matrigali wrote:
I would rather wait for an approved standard so that we don't later
get caught with apps depending on a non-standard behavior that we
might want to change in the future to meet a standard.
From the provided info it does not even look like there is a defacto
standard adopted
I would rather wait for an approved standard so that we don't later
get caught with apps depending on a non-standard behavior that we
might want to change in the future to meet a standard.
From the provided info it does not even look like there is a defacto
standard adopted by multiple db's.
/mi
Hi Dag,
We are also adding support for this via a JDBC ESCAPE in JDBC 4.1
The current versions of Sybase support TOP and SQL Anywhere and MS
SQL Server supports it as well
INFORMIX IDS supports Limit
Regards
lance
On Jul 9, 2009, at 10:06 AM, Dag H. Wanvik wrote:
Kathey Marsden writes
Kathey Marsden writes:
> I am hesitant to introduce behavior that is not standard compliant,
> but may be less hesitant if it is a sort of implied industry standard.
> What other database products do/do not support this syntax?
* MySQL allows it in their LIMIT construct, cf.
http://dev.mysql.
Dag H. Wanvik wrote:
Hi folks,
I have a working patch sitting on DERBY-4208. I am wondering if this
is a fix we should consider including for 10.5.2?
The pro argument is that this is a usability issue, and to the extent
it forces the app to construct SQL on the fly, makes the app more
vulnerabl
Hi folks,
I have a working patch sitting on DERBY-4208. I am wondering if this
is a fix we should consider including for 10.5.2?
The pro argument is that this is a usability issue, and to the extent
it forces the app to construct SQL on the fly, makes the app more
vulnerable to injection attacks
20 matches
Mail list logo
