Simple question, is there any way to omit the double quote in PostgreSQL?
Here is an example, giving select * from A;, I will retrieve ERROR: relation "a" does not exist, and I would have to give select * from "A"; to get the real result.
Is there any way not to do the second and instead do the first on PostgreSQL?
Your problem with this query started when you created your table. When you create your table, don't use quotes.
Use this:
CREATE TABLE a ( ... );
Not this:
CREATE TABLE "A" ( ... );
The latter will make it so that you always have to quote it later. The former makes it a normal name and you can use SELECT * FROM a; or SELECT * FROM A;
If you can't just recreate your table, use the ALTER TABLE syntax:
ALTER TABLE "A" RENAME TO a;
double quotes are required if you include capital letters in your table name in postgres
to avoid the requirements name your table "a"
Postgresql has some particular behaviour in regard to quoting and case sentivity: it folds every non-quoted identifier to lower case (also at creation time) and then works case-sensitively.
Double quotes in identifiers are only needed when the identifier (table name, column name, etc) was defined (at schema creation time) with uppercase letters (some or all) and between double quotes.
In that case (which I advice against), when you use that identifier, you must type it in the same way: case sensitively (type upper/lower case letter exactly as defined) and between double quotes.
In other cases, you can use non-quoted identifiers and work always case-insensitively.
Don't use upper case letter in your table name or it's column name, if you are using such thing then the postgres will required double quote for accessing it.
Please see the detailed description of what is happening here.
The PostgreSQL server table names are case-sensitive, but forced to be lower-case by default: when you type CREATE TABLE AAA, it will become CREATE TABLE aaa before the query execution.
Double-quoted names keep their case as it was, so after CREATE TABLE "AaA" you get the table AaA and have to write it double-quoted again and again.
Have no idea why did they do so :)
Related
I am new to PostgreSQL and trying the below two scenarios:
Select a column name which already has a forward slash(/) in database (Road/Highway)
Using case on same column along with index
Select Road/Highway,
case
when index(upcase(Road/Highway), 'xturn') > 0 then 2
else 0
end as preferred_road
from abc_data;
But I am getting syntax error near index and for slash it is only taking Road.
Generally / means "division", so your column name is non-standard, much like working with keyword column names, column names with special characters must be quoted with double quotes. Use "Road/Highway" when referring to the column.
I have a table Department with 2 columns, DEPT_CODE the PK and DEPT_NAME and both have data types name. I inserted:
INSERT INTO public."Department"("DEPT_CODE", "DEPT_NAME")
VALUES ('CIS', 'Computer Info Systems');
then I want to delete it so I wrote:
DELETE FROM public."Department"
WHERE 'DEPT_CODE' = 'CIS';
This didn't delete the row (I used the delete script provided by pgadmin). If I don't use quote for the 'DEPT_CODE', it gave an error:
ERROR: column "dept_code" does not exist
LINE 2: WHERE DEPT_CODE = 'CIS';
Idk what to do. Every tutorial I see seemed to be able to delete just fine, why not mine? This is my first time using pgadmin-postgres.
As documented in the manual identifiers (column & table names) need to be enclosed in double quotes. Single quotes are only for string constants.
And because you used the dreaded double quotes for the table and column names when you created the table, you now need to use them always:
DELETE FROM public."Department"
WHERE "DEPT_CODE" = 'CIS';
^ ^
| column name | string constant
It's strongly recommended to avoid those dreaded quoted identifiers completely. So never use double quotes when you create tables, then you never need to use them when working with the tables
i have table having below records.The below product description are given by user in textbox in
front end(asp.net).The product description will come with single quotes or double quotes.i want to insert in the table.so how can we check whether single quotes or double quotes are exists in the
the input and insert value in the table.please help.
String s=Textbook
CREATE TABLE Product_Details(Product_Description varchar(50))
Required Output
Product_Description
-------------------
STORE('COVERED)
STEEL("ROOFED)
Insert statement will be differ for above two string?.
I'm not sure what exactly what you are looking for. You should be able to store text with quotes or double quotes without any trouble (note, I'm testing on Postgresql 9.4, don't have 9.2).
The problem is sometimes creating the text with the single quotes. In those cases it is common to have two single quotes like this insert into product_details values ('STORE(''COVERED)') The double quotes (") should not be a problem. You can use the syntax E'STORE(\'COVERED)' instead of the two quotes. Sometimes more readable.
If you just want to check if there are ' or "" in the input, this check is convenient:
select length(replace(product_description,'''',''))!=length(product_description),
length(replace(product_description,'"',''))!=length(product_description)
which return true/false columns telling if single-quote exists in string in first column and double-quote in the latter.
To delete the quotes in string you can do:
select replace(replace(product_description,'"',''),'''','')
Best regards,
Bjarni
I wonder if someone could have an idea what is going wrong with this simple query on a hstore column in PostgreSQL 9.2
The queries are runned in pgAdmin
select attributeValue->"CODE_MUN" from shapefile_feature
returns: « attributevalue » column does not exists
when doing:
select * from shapefile_feature;
all the columns are returned including attributeValue, the hstore column
what is the problem?
PostgreSQL distinguish between "identifiers" and 'literal'. Identifiers are schema, table, column's, .. names, literals are others. A attribute in hstore are not SQL identifiers. So you have to pass their names as literals. Operator "->" is only shortcut for function "fetchval(hstore, text)" with possibility be indexed.
select attributeValue->'CODE_MUN' from shapefile_feature
is internally transformed to (don't do this transformation by self!)
select fetchval(attributeValue, 'CODE_MUN') from shapefile_feature
on buggy example in transformed form, you can better understand to error message:
select fetchval(attributeValue, "CODE_MUN") from shapefile_feature
PostgreSQL tries to find column "CODE_MUN" in shapefile_feature, bacause used double quotes means identifiers (in case sensitive notation).
I am using Ubuntu and PostgreSql 8.4.9.
Now, for any table in my database, if I do select table_name.name from table_name, it shows a result of concatenated columns for each row, although I don't have any name column in the table. For the tables which have name column, no issue. Any idea why?
My results are like this:
select taggings.name from taggings limit 3;
---------------------------------------------------------------
(1,4,84,,,PlantCategory,soil_pref_tags,"2010-03-18 00:37:55")
(2,5,84,,,PlantCategory,soil_pref_tags,"2010-03-18 00:37:55")
(3,6,84,,,PlantCategory,soil_pref_tags,"2010-03-18 00:37:55")
(3 rows)
select name from taggings limit 3;
ERROR: column "name" does not exist
LINE 1: select name from taggings limit 3;
This is a known confusing "feature" with a bit of history. Specifically, you could refer to tuples from the table as a whole with the table name, and then appending .name would invoke the name function on them (i.e. it would be interpreted as select name(t) from t).
At some point in the PostgreSQL 9 development, Istr this was cleaned up a bit. You can still do select t from t explicitly to get the rows-as-tuples effect, but you can't apply a function in the same way. So on PostgreSQL 8.4.9, this:
create table t(id serial primary key, value text not null);
insert into t(value) values('foo');
select t.name from t;
produces the bizarre:
name
---------
(1,foo)
(1 row)
but on 9.1.1 produces:
ERROR: column t.name does not exist
LINE 1: select t.name from t;
^
as you would expect.
So, to specifically answer your question: name is a standard type in PostgreSQL (used in the catalogue for table names etc) and also some standard functions to convert things to the name type. It's not actually reserved, just the objects that exist called that, plus some historical strange syntax, made things confusing; and this has been fixed by the developers in recent versions.
According to the PostgreSQL documentation, name is a "non-reserved" keyword in PostgreSQL, SQL:2003, SQL:1999, or SQL-92.
SQL distinguishes between reserved and non-reserved key words. According to the standard, reserved key words are the only real key words; they are never allowed as identifiers. Non-reserved key words only have a special meaning in particular contexts and can be used as identifiers in other contexts. Most non-reserved key words are actually the names of built-in tables and functions specified by SQL. The concept of non-reserved key words essentially only exists to declare that some predefined meaning is attached to a word in some contexts.
The suggested fix when using keywords is:
As a general rule, if you get spurious parser errors for commands that contain any of the listed key words as an identifier you should try to quote the identifier to see if the problem goes away.