I know this sounds like an "opinion" question, but I don't think it is.
Normally, I would consider not using "user" as a table name as it is a reserved word, and I would rather not bother having to deal with it when I write native SQL queries.
But I am not writing native SQL queries, but am having Symfony and the Doctrine ORM perform all the queries. And when I execute php bin/console make:user, Symfony prompts me to select the class name User which results with user as the table name. Furthermore, most of the tutorials I have read also use the name user. If using the name user is what is most common for other developers, I would rather stay consistent.
Most of the time, I don't have any issues, but every now and then, Doctrine crashes because it is querying the Postgres internal user table and not public.user. As a workaround, I tried adding * #ORM\Table(schema="public") to the User entity, but then when making migrations, it tries to duplicate the record resulting in errors. Maybe Symfony/Doctrine needs to be configured somewhere as using the public schema?
Thanks
Since my question was "Should the table name “user” be used in a Symfony project?", the following doesn't answer the question, but I am still posting it should it be helpful for others. Perhaps I will change the title to "How to use the table name “user” in a Doctrine project?", but not sure whether doing so is kosher.
I've since discovered other's experiencing issues resulting from this topic:
https://github.com/doctrine/dbal/issues/1222
https://github.com/symfony/maker-bundle/pull/545
Also found the following at doctrine-adding-mapping:
Be careful not to use reserved SQL keywords as your table or column
names (e.g. GROUP or USER). See Doctrine’s Reserved SQL keywords
documentation for details on how to escape these. Or, change the table
name with #ORM\Table(name="groups") above the class or configure the
column name with the name="group_name" option.
Which directed me to quoting-reserved-words which directed me to escape the name using ticks.
* #ORM\Table(name="`user`")
There is no table user in PostgreSQL.
Tutorials that use user as a table name are not trustworthy. However, if you consistently use double quotes, there should be no problem. Since you claim to have problems with native queries, you might have forgotten that occasionally.
One possible source of confusion is that there is a function named user in PostgreSQL. So if you use user in a context where a function is possible, you'll get a function call. If you use it with schema qualification, you will get an error that there is no such object. Otherwise, you will get a syntax error:
test=> SELECT user;
user
---------
laurenz
(1 row)
test=> SELECT * FROM user;
user
---------
laurenz
(1 row)
test=> TABLE user;
ERROR: syntax error at or near "user"
LINE 1: TABLE user;
^
test=> SELECT * FROM public.user;
ERROR: relation "public.user" does not exist
LINE 1: SELECT * FROM public.user;
^
Related
I am not so into PostgreSQL and pgAdmin 4 and I have the following doubt.
Following a screenshot of what I can see in my pgAdmin4:
As you can see it is performing this very simple query:
SELECT * FROM public."Example"
ORDER BY id ASC
The thing that I am not understanding is what is this public name in front of the Example table name. What is it?
I was trying to perform a query in this way but it is not working:
SELECT * FROM Example
ORDER BY id ASC
It give me a syntax error. I often used MySql and in MySql it is working.
I tried to replace the query in this way:
SELECT * FROM "Example"
ORDER BY id ASC
and so it is working. So it means that in PosgreSQL database the "" around the table name are mandatory?
The thing that I am not understanding is what is this public name in front of the Example table name. What is it?
As said in postgres documentation:
"By default tables (and other objects) are automatically put into a schema named "public". Every new database contains such a schema."
So it means that in PosgreSQL database the "" around the table name
are mandatory?
Not really but you need to use it if you are using reserved keywords (such as "user","name"and other)or if your table's name contains uppercase(it's your case) letters. Anyways, in this case if you can it's better change your table's name.
You should change your table name to all alphabet in lowercase then try again with
select * from example
Problem
I want to prevent a database user from discovering other tables through the use of queries like select * from pg_tables; by adding sanitization in the application that executes the query.
I'm busy investigating how to limit access to a PostgreSQL database for queries coming through an application layer where I can still sanitize a query with code. The user does not connect straight to the database. They can execute queries through an application layer (e.g. query is passed through as text and then executed by my application).
I've already enabled Row Security Policies (row level security) and the user is accessing their data through a view, so "access to data" has been solved (I believe). The problem I'm trying to solve now is to prevent them from "seeing" other tables in the database, especially the built-in PG tables.
The only grant the user has is grant select on my_view to my_user_role;
Assumption / attempted solution
My assumption is that a user can't access a table without explicitly writing it into the query, so if I were to look for certain keywords in the query string, I can reject a query without executing it. E.g. if the clause/characters "pg_tables" are anywhere in the query, then I can reject it. But, this feels naive.
const query = "select * from pg_tables;";
const flagged = query.includes("pg_tables");
if (flagged) throw Error("Not allowed!");
// Continue to run the user's query
^ This would work reliably if the only way to access a table like pg_tables is to type that out explicitly.
Question
Is there a way to access a table like pg_tables without naming it explicitly, in PostgreSQL [given the context above]?
An example of a similar situation in javascript is if you have a function fooBar(), then you can access it indirectly by calling global["foo" + "Bar"]() – hence not using the text "fooBar" exactly.
I am migrating this Oracle command to PostgreSQL:
CREATE SYNONYM &user..emp FOR &schema..emp;
Please suggest to me how I can migrate the above command.
PostgreSQL does not support SYNOSYM or ALIAS. Synonym is a non SQL 2003 feature implemented by Microsoft SQL 2005 (I think). While it does provide an interesting abstraction, but due to lack of relational integrity, it can be considered a risk.
That is, you can create a synonym, advertise it to you programmers, the code is written around it, including stored procedures, then one day the backend of this synonym (or link or pointer) is changed/deleted/etc leading to a run time error. I don't even think a prepare would catch that.
It is the same trap as the symbolic links in unix and null pointers in C/C++.
But rather create a DB view and it is already updateable as long as it contains one table select only.
CREATE VIEW schema_name.synonym_name AS SELECT * FROM schema_name.table_name;
You don't need synonyms.
There are two approaches:
using the schema search path:
ALTER DATABASE xyz SET search_path = schema1, schema2, ...;
Put the schema that holds the table on the search_path of the database (or user), then it can be used without schema qualification.
using a view:
CREATE VIEW dest_schema.tab AS SELECT * FROM source_schema.tab;
The first approach is good if you have a lot of synonyms for objects in the same schema.
It seems PostgreSQL does not allow to create a database table named 'user'. But MySQL will allow to create such a table.
Is that because it is a key word? But Hibernate cannot identify any issue (even if we set the PostgreSQLDialect).
user is a reserved word and it's usually not a good idea use reserved words for identifiers (tables, columns).
If you insist on doing that you have to put the table name in double quotes:
create table "user" (...);
But then you always need to use double quotes when referencing the table. Additionally the table name is then case-sensitive. "user" is a different table name than "User".
If you want to save yourself a lot of trouble use a different name. users, user_account, ...
More details on quoted identifiers can be found in the manual: http://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
It is possible to specify tablename with JPA with next syntax:
#Table(name="\"user\"")
We had this same issue time ago, and we just changed the table name from user to app_user. Due to the use of Hibernate/JPA. We thought it would be easier this way.
Hope this little fix will help someone else.
You can create a table user in a schema other than public.
The example:
CREATE SCHEMA my_schema;
CREATE TABLE my_schema.user(...);
Trailing underscore
The SQL standard explicitly promises to never use a trailing underscore in any keyword or reserved word.
So, to avoid conflicts with any of the over a thousand keywords and reserved words used by various database engines, I name all my database identifiers with a trailing underscore. (Yes, really, over a thousand keywords reserved — I counted them.)
Change this:
CREATE TABLE user ( … ) ;
… to this:
CREATE TABLE user_ ( … ) ;
I do this as a habit for all database names: schemas, tables, columns, indexes, etc.
As an extra benefit, this practice makes quite clear in documentation, email, and such when referring to a programming language variable named user versus the database column user_. Anything with a trailing underscore is obviously from the database side.
I have an issue with psql. I am trying to select the records from a table but psql acts like the table doesnt exist. I have tried finding it and found that it resides in the 'public' schema. I have tried selecting from this table like so:
highways=# SELECT * FROM public.CLUSTER_128000M;
This does not work stating the following:
ERROR: relation 'public.CLUSTER_128000M' does not exist
I know that it definetly exists and that it is definetly in the 'public' schema so how can I perform a select statement on it?
Edit:
This was caused by useing FME to create my tables. As a result FME used " marks on the table names making them case sensitive. To reverse this see the comments below.
This issue was caused by the third party software FME using quotes around the names of the tables at time of creation. The solution to make the tables useable again was to use the following command:
ALTER TABLE "SOME_NAME" RENAME TO some_name