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, 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
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
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
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])
[GENERAL] last comma inside "CREATE TABLE ()" statements
Is it against the SQL standard to accept a trailing comma in a table declaration? 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. -- PHEDRE: Insensée, où suis-je ? et qu'ai-je dit ? Où laissé-je égarer mes voeux et mon esprit ? (Phèdre, J-B Racine, acte 1, scène 3) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
