PGSQL- syntax error at or near "-"

Question

I have tried to run an INSERT query in Pgsql using PgAdmin. The table name is todo-list. However, when I try to run it, an error message appears:-

syntax error at or near "-"
LINE 1: INSERT INTO todo-list(todo_title,todo_description,todo_image...
 ^

The query that I want to run is

INSERT INTO todo-list(todo_title,todo_description,todo_image,todo_status) VALUES("efrgthnj","wefrgtbhnj","qwefgrthj",1)

I tried using "todo-list", but that didn't work either. What should I do?

• sticky bit: If you use special characters in object names or want them do be case sensitive, you must enclose them with double quotes: "todo-list" But preferably you'd do yourself a favor, if you want special characters in object names nor use case sensitives object names.
• Vérace: Hi, and welcome to dba.se! You_should_use_python_case_to_name_your_tables! Also_suggest_that_you_only_user_lower_case_letters! Use_the_underscore_as_a_separator! See_here_for_examples!
• Skumar: @stickybit I tried using "todo-list", but that didn't work either
• user1822: String constants need to be enclosed in single quotes in SQL

Answer 1

As others have quite rightly pointed out, your proposed table name (todo-list) does not conform to the MySQL rules for an Identifier and so MySQL can't work out what to do with it.

You could try wrapping it in back-ticks (`, over by the "1" key on your keyboard) - not single (') or double (") quotes - as in ...

insert into `todo-list` ( ... 

... but, frankly, you'll be far better off not getting into the habit of using "invalid" identifiers in the first place. Eventually, they always come back and bite you.

All lower case names with underscores in between "words" is a perfectly good convention, as you appear to have used for all your column names.

• user1822: But Skumar uses Postgres, not MySQL. So the name has to be quoted with double quotes (following the SQL standard). The second problem are the invalid string constants using double quotes
• Phill W.: Oops! Apologies. However, the principle of simply /avoiding/ this problem in the first place still stands, regardless of DBMS.