Sample Header Ad - 728x90

why is the name `loop` treated differently in PostgreSQL

1 vote
1 answer
348 views
I issue the following DDL: CREATE TABLE foo ( loopa INTEGER, loop INTEGER ); Then, examining the DDL in the server (using a client-side tool like DbVisualizer - sorry don't know the query to produce it directly) I see the following: CREATE TABLE foo ( loopa INTEGER, LOOP INTEGER ); Observe the change in case for the column named loop but not for the one named loopa. Looking at the list of SQL keywords loop doesn't appear to be a keyword. Why then, this selective change? This *seems* to be related to a problem I am having with a trigger trying to access a column loop in a table where I get: Exception in thread "main" org.postgresql.util.PSQLException: ERROR: record "new" has no field "loop" (where I get the same error regardless of whether the code in the trigger function access the field as NEW.LOOP or NEW.loop) ***UPDATE*** The upper-casing *seems* to be an artifact of DbVisualizer. psql shows: psql (9.1.13) Type "help" for help. foo-test=> \dS+ foo Table "test.foo" Column | Type | Modifiers | Storage | Description --------+---------+-----------+---------+------------- loopa | integer | | plain | loop | integer | | plain | Has OIDs: no Yet this still doesn't explain why the PostgreSQL engine apparently doesn't allow my trigger to access NEW.loop. When I rename the column (and the trigger code) to loopi everything appears to work fine. So, there is likely something deeper at work here than just a DbVisualizer glitch. I'll try to create a SSCCE later. ***UPDATE 2*** A SSCCE for the trigger problem has been created here .
Asked by Marcus Junius Brutus (3409 rep)
Sep 16, 2014, 07:59 PM
Last activity: Sep 16, 2014, 10:30 PM