array syntax and geometric type syntax
I am trying to make sense of geometric literal syntax in and out of array syntax. I cannot figure out a general rule: sometimes single quotes work, sometimes double quotes work, and inside and outside of array literals the rules are different an seemingly inconsistent.
Examples of all the weird cases are below. If someone could explain what the SQL parser is really looking for, and what the "best" or "most correct" way is, I would be grateful.
Thanks,
Dan
------------------------
Examples:
db=# create temporary table x (p point);
CREATE TABLE
Can't use bare point notation:
db=# insert into x values ( (1,2) );
ERROR: column "p" is of type point but expression is of type record
HINT: You will need to rewrite or cast the expression.
Can use single-quoted points:
db=# insert into x values ( '(1,2)' );
INSERT 0 1
Can't use double-quoted points:
db=# insert into x values ( "(1,2)" );
ERROR: column "(1,2)" does not exist
LINE 1: insert into x values ( "(1,2)" );
Function notation works, as expected:
db=# insert into x values (point(1,2));
INSERT 0 1
Casting works, as expected:
db=# insert into x values ( '(1,2)'::point );
INSERT 0 1
Values print without quotes:
db=# select * from x;
p
-------
(1,2)
(1,2)
(1,2)
(3 rows)
OK, now try an array of points:
db=# create temporary table y (pa point[]);
CREATE TABLE
ARRAY[] with single quoted value doesn't work:
db=# insert into y values (array[ '(1,2)' ]);
ERROR: column "pa" is of type point[] but expression is of type text[]
HINT: You will need to rewrite or cast the expression.
ARRAY[] with double quoted value doesn't work:
db=# insert into y values (array [ "(1,2)" ]);
ERROR: column "(1,2)" does not exist
LINE 1: insert into y values (array [ "(1,2)" ]);
^
Array[] with casting a quoted string works:
db=# insert into y values (array [ '(1,2)'::point ]);
INSERT 0 1
ARRAY[] with point() works:
db=# insert into y values (array [ point(1,2) ]);
INSERT 0 1
{} notation with unquoted value inside doesn't work:
db=# insert into y values ('{ (1,2) }');
ERROR: invalid input syntax for type point: "(1"
{} notation with double quotes inside works!!:
db=# insert into y values ('{ "(1,2)" }');
INSERT 0 1
{} with cast doesn't work:
db=# insert into y values ( '{ ''(2,3)''::point }');
ERROR: invalid input syntax for type point: "'(2"
{} with point() doesn't work:
db=# insert into y values ( '{ point(2,3) }');
ERROR: invalid input syntax for type point: "point(2"
Values print with {} and double-quote notation inside:
db=# select * from y;
pa
-----------
{"(1,2)"}
{"(1,2)"}
{"(1,2)"}
(3 rows)
On Thu, Aug 13, 2009 at 11:02:37AM -0400, Dan Halbert wrote:
I am trying to make sense of geometric literal syntax in and out of
array syntax. I cannot figure out a general rule: sometimes single
quotes work, sometimes double quotes work, and inside and outside of
array literals the rules are different an seemingly inconsistent.
I'm sure it doesn't look like it, but literal syntax is the same
everywhere. What's confusing is that there's no visual difference
between a text literal any any other type--hence the error messages you
get back from PG are a bit confusing.
Firstly, column references are always at the "top-level" and are always
in double quotes. The other double quotes you were using were "inside"
a literal and hence subject to rules specific to that datatype's literal
input code.
The nicer syntax to distinguish things is to use:
TYPENAME 'literal'
in code. For example:
SELECT INT '1', FLOAT8 '1.1', NUMERIC '1.1';
Points are fun, because although the following look similar and have the
same result:
SELECT POINT '(1,2)', POINT (1,2);
They're actually doing very different things underneath. The first is
a straight point literal, the second is calling the point function and
giving its two parameters. I.e. it's short for:
SELECT POINT (FLOAT '1', FLOAT '2');
Array and Record literals are more complicated because they have to deal
with nesting of things and hence can get quite baroque. Lets go with
arrays first, because that's what your question was about. The basic
literal format is:
'{"elem1","elem2","elem_n"}'
So inside the single quotes, used to indicate a literal, there are
double quotes that separate each element. However all these double
quotes are just a waste of space most of the time, so unless there
are any strange characters (i.e. commas, braces, double quotes or
backslashes if I remember right) it doesn't bother with the double
quotes. For example, if we evaluate the above:
SELECT '{"elem1","elem2","elem_n"}'::TEXT[];
(sadly the normal literal syntax doesn't work for arrays) we get back:
{elem1,elem2,n}
So, PG has read in the literal, turned it into a real value internally,
and then converted it back to a literal to show you the result. These
two conversions have resulted in you getting something different back,
but they both represent the same thing as far as PG is concerned.
--
Sam http://samason.me.uk/
I am trying to make sense of geometric literal syntax in and out of array syntax. I cannot figure out a general rule: sometimes single quotes work, sometimes double quotes work, and inside and outside of array literals the rules are different an seemingly inconsistent.
Examples of all the weird cases are below. If someone could explain what the SQL parser is really looking for, and what the "best" or "most correct" way is, I would be grateful.
I'm not sure you have a question here that you didn't answer yourself.
Postgres is stricter than most dbms's about typing. It doesn't like to
guess about what you probably meant. It's both a blessing and a curse.
But you get used to it.
You've already gone through what works and what doesn't. Just do what
works. :) But to answer the question about why the quotes when it is a
point array: Postgres is correctly interpreting and storing your point
arrays. But arrays are output as comma separated lists and since your
points have embedded commas, it quotes them.
Scott
On Thu, Aug 13, 2009 at 12:31:29PM -0400, Dan Halbert wrote:
Perhaps I should have mentioned that initially.
In retrospect everything is easy!
SELECT ARRAY[1,2,1+2]::INT[];
works fine.
I'd not put a cast into that one. I can't see any performance reason
why it's bad, I think it's mainly because it may mask other problems
later on. It's not going to affect much fundamental either way though.
--
Sam http://samason.me.uk/