Roger Binns wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/11/12 18:25, Mark Brand wrote:
You mentioned that this extra AS might help avoid ambiguities and
errors. The only example of this you mentioned was where aliases names
with spaces are not quoted. Do you have cases of this in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/11/12 18:25, Mark Brand wrote:
> You mentioned that this extra AS might help avoid ambiguities and
> errors. The only example of this you mentioned was where aliases names
> with spaces are not quoted. Do you have cases of this in mind that
> wou
The misspelling of NATURAL would be caught by a warning for JOIN
without ON constraint.
True. And other possible errors could be caught by missing AS.
Really?
In my opinion, it's actually a good idea to leave out the AS in table
aliases since SQL-92 and many or most implementations do not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/11/12 15:46, Mark Brand wrote:
> A warning for "missing" AS would create noise and serve no purpose.
Then ignore/don't use it for your perfect code!
Other developers do use their own code (that could have been written years
ago), other code and
Nico Williams wrote:
On Thu, Nov 1, 2012 at 5:18 PM, Mark Brand wrote:
Why should the "missing" AS even be a warning in lint mode? SQL-92 does not
mandate it. One of the most important implementations does not even accept
it. Do you know of any SQL implementation that requires an AS here?
To c
On Thu, Nov 1, 2012 at 5:18 PM, Mark Brand wrote:
> Why should the "missing" AS even be a warning in lint mode? SQL-92 does not
> mandate it. One of the most important implementations does not even accept
> it. Do you know of any SQL implementation that requires an AS here?
To catch misspellings
On 01/11/12 14:32, Mark Brand wrote:
My point is that the proposed lint mode should worry more about 2) than
1).
I didn't think they are mutually exclusive. The class of probable errors
detected overlaps.
But the "missing" AS is not a probable error. It's standard and
well-established. So I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/11/12 14:32, Mark Brand wrote:
> My point is that the proposed lint mode should worry more about 2) than
> 1).
I didn't think they are mutually exclusive. The class of probable errors
detected overlaps.
> ... as Oracle at least doesn't allow i
The optionality of "AS" when aliasing column names is not strange.
Oops. I see that I did not mean "column names". This is about table aliases.
You are missing the point :-) I am not arguing for syntax changes or
anything else in the core of SQLite or SQL.
No, I don't don't think I am mis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/11/12 12:33, Mark Brand wrote:
> The optionality of "AS" when aliasing column names is not strange.
You are missing the point :-) I am not arguing for syntax changes or
anything else in the core of SQLite or SQL.
Instead in an additional "lint
Roger Binns wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31/10/12 07:27, Jonas Malaco Filho wrote:
Maybe there could be a strict switch.
There is a ticket for a "lint" mode that would help catch common issues
where there are possibly problems. This is another example of something
a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31/10/12 07:27, Jonas Malaco Filho wrote:
> Maybe there could be a strict switch.
There is a ticket for a "lint" mode that would help catch common issues
where there are possibly problems. This is another example of something
appropriate for it to
oh, that makes sense. Thanks for clarifying.
Sam
-
We're Hiring! Seeking passionate Flex or C# developer in the Washington
D.C. Contact care...@blinemedical.com
On Wed, Oct 31, 2012 at 10:18 AM, Richard Hipp wrote:
> On Wed, Oc
Maybe there could be a strict switch. It could also be useful for
developing/testing stuff on SQLite that would later be sent to different a
RDBMS or a custom SQL processor.
*Jonas Malaco Filho*
2012/10/31 Richard Hipp
> On Wed, Oct 31, 2012 at 10:13 AM, Ryan Johnson
> wrote:
>
> > On 31/10/2
On Wed, Oct 31, 2012 at 10:13 AM, Ryan Johnson
wrote:
> On 31/10/2012 9:54 AM, Samuel Neff wrote:
>
>> We wrote a query and intended to use a "natural" join but had a typo and
>> wrote "natrual" join instead. We were surprised this query was processed
>> without error and performed a cross join.
On Wed, Oct 31, 2012 at 9:54 AM, Samuel Neff wrote:
> We wrote a query and intended to use a "natural" join but had a typo and
> wrote "natrual" join instead. We were surprised this query was processed
> without error and performed a cross join.
>
> Example:
> sqlite> select * from a natrual joi
On 31/10/2012 9:54 AM, Samuel Neff wrote:
We wrote a query and intended to use a "natural" join but had a typo and
wrote "natrual" join instead. We were surprised this query was processed
without error and performed a cross join.
That must have been a delightful one to track down...
It's due t
We wrote a query and intended to use a "natural" join but had a typo and
wrote "natrual" join instead. We were surprised this query was processed
without error and performed a cross join.
Example:
SQLite version 3.7.6.3
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sq
18 matches
Mail list logo