Re: [GENERAL] last comma inside CREATE TABLE () statements
Heh.. Actually, those queries look quite good if you centre them in a
page -- Assuming all characters are the same width anyway. SELECT,
FROM, and other key words go onto the left column along with comma's,
and the relevant database columns, tables, and where clauses go on the
right. With a good naming convention I don't even have to look at the
left hand side of the query but rather just the list of entities on
the right. It also means every line has a left side and a right side.
Anyway, not that it matters much but If the loose grammar is
implemented it should be optional and off by default.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
- Original Message -
From: will trillich [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, April 27, 2001 12:56 AM
Subject: Re: [GENERAL] last comma inside CREATE TABLE () statements
On Thu, Apr 26, 2001 at 10:38:42AM -0400, Rod Taylor wrote:
Gah.. just put comma's at the beginning...
Oh, now THAT's intuitive:
. To be
, or not to be
, that is the question
. Whether 'tis nobler...
Charming. :)
SELECT bleah
, blah
, otherthing
FROM arghh
, feh
, fah
WHERE ( blah in ('1'
, '2'
, '3')
OR otherthing IS TRUE
)
OR bleah IS FALSE
Oh, and indent nicer. You can remove virtually any line (except
the
ones with commands in them) without any issues.
What that does, is it transfers the location of the problem. Now
the comma is effectively in FRONT of most terms, except the
FIRST.
An alternative compromise:
select
first
,
second
,
third
,
fourth
from
alpha
,
bravo
,
charlie
;
It's odd to use a whole line just for a florkin' comma, but in vi
2ddkkP or 2ddP will rearrange things nicely, while
keeping the purists at bay (not to mention any names, but You
Know Who You Are :).
I'd still prefer to ALLOW (but not DEMAND) 'empty after last
comma'. Or if you're determined to go for 'empty before first
comma':
update tbl
set
,one = something
,two = something-else
,three = fn('hgttg',42)
,four = that
;
But i hope you'll agree that this is more obtuse than we need to
be. Not to mention the speedbump effect it'll have on the person
who's got to look over your code next month.
This looks much nicer, imho --
update tbl
set
one = something ,
two = something-else ,
three = fn('hgttg',42) ,
four = that,
;
After all, the comma is of no importance to the conceptual task
we're after: i don't care if there's a token separating those
assignments -- i'm interested in the fields and the values being
assigned to them. The commas are just there to help us predict
that the compiler will understand what we're after.
And it's easy to rearrange those lines in a text editor without
having to be paranoid about Do i need to add a comma somewhere?
Should i look to see if i should take one out?
Computers should work. People should think. Data! Mow the lawn!
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
---(end of
broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [GENERAL] last comma inside CREATE TABLE () statements
On Sunday 22 April 2001 10:21, you wrote: however, this seems like a reasonable idea that would not introduce any major problems. I have no objections, if someone wants to submit a grammar patch. regards, tom lane Please don't. IMHO This would be an unnecessary 'extension' to postgresql that would allow scipts and a syntax that will generate errors when used on other DB's. We have moved all our projects from an Oracle 8 environment to postgress and really appreciate the flexibility, and quality without the undue complexity of running Oracle. We were able to do this fairly easily (about 1 day for half a dozen databases/applications each with about 5gig data) because our schema scripts ran without error the first time. By permitting sloppy syntax 'portability' could become 'no-so-portable' . Yes we could just make sure that we avoid sloppy syntax but it is great to have the parser say 'hey that was wrong, fix it and I won't complain again'. I'm more than happy to fix it now and know that I can use it later without hassle. Just my 2 (okay maybe 3) cents. Mike. === Mike Finn Tactical Executive Systems [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] last comma inside CREATE TABLE () statements
On Sun, 22 Apr 2001, Louis-David Mitterrand wrote: Is it against the SQL standard to accept a trailing comma in a table declaration? Yes it is. CREATE TABLE "currency" ( currency_id varchar(3), rate float, BOOM! parse error ); As in perl, it would make life easier to simply ignore/accept a trailing comma on table declarations. Yeah it would, wouldn't it? ;) -laex ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] last comma inside CREATE TABLE () statements
Louis-David Mitterrand [EMAIL PROTECTED] writes: Is it against the SQL standard to accept a trailing comma in a table declaration? Yes ... CREATE TABLE "currency" ( currency_id varchar(3), rate float, BOOM! parse error ); As in perl, it would make life easier to simply ignore/accept a trailing comma on table declarations. ... however, this seems like a reasonable idea that would not introduce any major problems. I have no objections, if someone wants to submit a grammar patch. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] last comma inside CREATE TABLE () statements
Tom Lane wrote: Louis-David Mitterrand [EMAIL PROTECTED] writes: Is it against the SQL standard to accept a trailing comma in a table declaration? Yes ... CREATE TABLE "currency" ( currency_id varchar(3), rate float, BOOM! parse error ); As in perl, it would make life easier to simply ignore/accept a trailing comma on table declarations. ... however, this seems like a reasonable idea that would not introduce any major problems. I have no objections, if someone wants to submit a grammar patch. I suppose it isn't a major problem, but enforcing strict grammar helps to show up inadvertent errors. Suppose I have a set of schema building files for a whole system; the way I do things, there may be fifty or more files, one per table. If one of these gets corrupted in editing (perhaps a line gets deleted by mistake) it would be nice to know about it through a parser error. Of course, an error may be such that the parser won't detect it, but why remove protection by gratuitously departing from the standard? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "If my people, which are called by my name, shall humble themselves, and pray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive their sin, and will heal their land."II Chronicles 7:14 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] last comma inside CREATE TABLE () statements
On Sun, Apr 22, 2001 at 07:44:46PM +0100, some SMTP stream spewed forth: Tom Lane wrote: Louis-David Mitterrand [EMAIL PROTECTED] writes: Is it against the SQL standard to accept a trailing comma in a table declaration? Yes ... CREATE TABLE "currency" ( currency_id varchar(3), rate float, BOOM! parse error ); As in perl, it would make life easier to simply ignore/accept a trailing comma on table declarations. ... however, this seems like a reasonable idea that would not introduce any major problems. I have no objections, if someone wants to submit a grammar patch. I can think of no place where this would be even remotely useful. Is it really that difficult to remove a comma? If it works now for *all* users of PostgreSQL, why should we change it? gh I suppose it isn't a major problem, but enforcing strict grammar helps to show up inadvertent errors. Suppose I have a set of schema building files for a whole system; the way I do things, there may be fifty or more files, one per table. If one of these gets corrupted in editing (perhaps a line gets deleted by mistake) it would be nice to know about it through a parser error. Of course, an error may be such that the parser won't detect it, but why remove protection by gratuitously departing from the standard? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "If my people, which are called by my name, shall humble themselves, and pray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive their sin, and will heal their land."II Chronicles 7:14 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
