Once upon a time (Thu, 25 Sep 2003 01:28:29 -0400) Tom Lane <[EMAIL PROTECTED]> uttered something amazingly similar to:
> Robert Creager <[EMAIL PROTECTED]> writes: > >> Seems like the correct behavior to me. When CONSTRAINT is given, the > >> name is not optional AFAICS. > > > True, but the second CREATE DOMAIN, which is a valid form, fails when > > preceded by the invalid form. This was the error I was referring to. > > Not the fact that I didn't know how to use domains ;-) If the > > transaction is bad after the first invalid CREATE DOMAIN, the error > > should say so, rather than waiting for a second valid statement to > > come along, shouldn't it? > > Uh, which part of "queries ignored until end of transaction block" > didn't you understand? I understand every word of it. Why doesn't that error come up after the first CREATE DOMAIN error, since I was in a transaction. Then it would of been perfectly clear that the transaction I was in needed to be rolled back. Rather that error doesn't occur until the second valid CREATE DOMAIN is executed. I was not aware of what Stephan indicated: "All errors are considered unrecoverable ones by PostgreSQL so after any error the transaction is in an effectively unusable state and should be rolled back". I know better now. It still seams that the "queries ignored until end of transaction block" should of been thrown after the first invalid CREATE DOMAIN. That's all. > > > begin; > > create domain test as integer constraint check( value > 0 ); > > -- ERROR: syntax error at or near "check" at character 42 > > create domain test as integer check( value > 0 ); > > -- ERROR: current transaction is aborted, queries ignored until end > > of transaction block Cheers, Rob -- 07:16:42 up 54 days, 23:48, 5 users, load average: 2.17, 2.06, 2.01
pgp00000.pgp
Description: PGP signature
