Thread: point -> double,double ?
What are the operators or functions to extract the x and y portions of a point? I can't find it in my book or in the online \do or \df output anywhere. thanks -- greg
On Fri, Jan 17, 2003 at 14:04:21 -0500,
Greg Stark <gsstark@mit.edu> wrote:
>
> What are the operators or functions to extract the x and y portions of a
> point? I can't find it in my book or in the online \do or \df output anywhere.
One way to do it is the following:
bruno=> select height(box('(0,0)','(1,2)'));
height
--------
2
(1 row)
bruno=> select width(box('(0,0)','(1,2)'));
width
-------
1
(1 row)
Replace the the non '(0,0)' point with the point of interest.
This only works for nonnegative values.
Greg Stark <gsstark@mit.edu> writes:
> What are the operators or functions to extract the x and y portions of a
> point? I can't find it in my book or in the online \do or \df output anywhere.
point[0] and point[1]. Not sure if this is adequately documented.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Greg Stark <gsstark@mit.edu> writes: > > What are the operators or functions to extract the x and y portions of a > > point? I can't find it in my book or in the online \do or \df output anywhere. > > point[0] and point[1]. Not sure if this is adequately documented. Thank you very much. It may also be that I just don't have the right book. The book I have seems to be more of a tutorial than a reference. Is there a recommended reference book for postgres? -- greg
Greg Stark <gsstark@mit.edu> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> point[0] and point[1]. Not sure if this is adequately documented. > Thank you very much. > It may also be that I just don't have the right book. The book I have seems to > be more of a tutorial than a reference. Is there a recommended reference book > for postgres? Book? Save a tree, use the online manuals ;-). I find this particular item documented at the bottom of http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/functions-geometry.html regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.edu> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> writes:
> >> point[0] and point[1]. Not sure if this is adequately documented.
>
> > Thank you very much.
Hm, this seems odd
slo=> select b,b[0],b[0][0] from t;
b | b | b
-----------------------------------------------+------------------------+---
(-75.493906,44.854114),(-75.493906,44.854114) | (-75.493906,44.854114) |
(1 row)
--
greg
Greg Stark <gsstark@mit.edu> writes:
> Hm, this seems odd
> slo=> select b,b[0],b[0][0] from t;
> b | b | b
> -----------------------------------------------+------------------------+---
> (-75.493906,44.854114),(-75.493906,44.854114) | (-75.493906,44.854114) |
> (1 row)
The problem here is that foo[m][n] is our notation for a
doubly-subscripted array --- and we don't have any concept in the type
system that a one-dimensional array is different from a two-dimensional
array. So the code goes down the primrose path of assuming that "b"
is a 2-D array of points, rather than expecting b[0] to yield a
separate datatype that should be separately subscripted.
We could perhaps hack something for this particular case, since box is
known not to be a general array but only a hardwired one-dimensional
array of points. I don't see a good general solution though.
Any thoughts?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Greg Stark <gsstark@mit.edu> writes: > > Hm, this seems odd > > > slo=> select b,b[0],b[0][0] from t; > > b | b | b > > -----------------------------------------------+------------------------+--- > > (-75.493906,44.854114),(-75.493906,44.854114) | (-75.493906,44.854114) | > > (1 row) > > The problem here is that foo[m][n] is our notation for a > doubly-subscripted array --- and we don't have any concept in the type > system that a one-dimensional array is different from a two-dimensional > array. So the code goes down the primrose path of assuming that "b" > is a 2-D array of points, rather than expecting b[0] to yield a > separate datatype that should be separately subscripted. I guess arrays must be some deep voodoo. [] doesn't show up in the list of operators. I would be happy if there was at least some way to trick the parser into doing the right thing. I'm surprised something like this doesn't work: slo=> select (b[0])[0] from t; ERROR: parser: parse error at or near "[" at character 14 > We could perhaps hack something for this particular case, since box is > known not to be a general array but only a hardwired one-dimensional > array of points. I don't see a good general solution though. > Any thoughts? If [] were a normal operator then other datatypes could define operations similar to point and box, but I imagine it's the way it is for some good reason in the parser level. -- greg
Greg Stark <gsstark@mit.edu> writes:
> I guess arrays must be some deep voodoo. [] doesn't show up in the list of
> operators. I would be happy if there was at least some way to trick the parser
> into doing the right thing. I'm surprised something like this doesn't work:
> slo=> select (b[0])[0] from t;
> ERROR: parser: parse error at or near "[" at character 14
Yeah, that was my first thought too. It might not be difficult to make
it work --- there's no production in gram.y to accept this, but if there
were then I think that the rest of the code would do the right thing.
> If [] were a normal operator then other datatypes could define operations
> similar to point and box, but I imagine it's the way it is for some good
> reason in the parser level.
You can make arrays of whatever datatype you want. The issue here
is just that there's a syntactic ambiguity between subscripting an
N-dimensional array and subscripting the element datatype of an
N-1-dimensional array ...
regards, tom lane