[BUGS] ST_Distance Issue

[Archana Sachin Ghag]

I am calculating distance from my current location with all available 
regions(polygons) in my table.
I am using ST_Distance method for this.
My regions are stored with SRID = 900913.

Distance for point in Europe from USA region is coming as 122.78.
How come this possible. These regions are so far.

Here is my query. Can you please suggest me how can I get actual distance in 
meters here.

SELECT distance
(st_geomfromtext('point(-123.574219125 47.8131546948944 0)', 900913),
st_geomfromtext('LINESTRING(-0.791015625 48.4874864798841,9.4921875 
54.5975278521139,27.59765625 55.3541353102106,36.38671875 
48.3124279040718,22.32421875 40.3465441211801,5.888671875 
43.8662180065564,-0.791015625 48.4874864798841)', 900913)
)

Query returns 122.785055218779

What is significance of SRID here. Am I missing something?
Which SRID should we use for general purpose.

Thanks,
Archana Ghag

Technology Architect
Microsoft Technology Center
Infosys Technologies Limited
B1, IT Park 1, Hinjawadi, Pune - 411057
Tel:  2022978913(VOIP) : +91-9850872739 (Mobile)
email: archana_g...@infosys.com


 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are 
not
to copy, disclose, or distribute this e-mail or its contents to any other 
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken
every reasonable precaution to minimize this risk, but is not liable for any 
damage
you may sustain as a result of any virus in this e-mail. You should carry out 
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this 
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: [BUGS] BUG #6293: JDBC driver performance

[Teun Hoogendoorn]

Hi Kris,
This is exactly what I'm doing. I understand your solution, but that's
not really an option for me (I have to change a lot of code). 

Maybe the driver can cache the ResultSetMetaData for the ResultSet?
BTW. I looked into the driver code to look for a solution for my problem. 
I came
across the following lines of code (in 
AbstractJdbc2ResultSetMetaData.java):

Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql.toString());
while (rs.next()) {
int table = rs.getInt(1);
int column = rs.getInt(2);
String columnName = rs.getString(3);
String tableName = rs.getString(4);
String schemaName = rs.getString(5);
int nullable = rs.getBoolean(6) ? 
ResultSetMetaData.columnNoNulls : ResultSetMetaData.columnNullable;
boolean autoIncrement = rs.getBoolean(7);
for (int i=0; i

Re: [BUGS] ST_Distance Issue

[Robert Haas]

On Thu, Nov 17, 2011 at 4:29 AM, Archana Sachin Ghag <
archana_g...@infosys.com> wrote:

> I am calculating distance from my current location with all available
> regions(polygons) in my table.
>
> I am using ST_Distance method for this.
>
> My regions are stored with SRID = 900913.
>
> ** **
>
> Distance for point in Europe from USA region is coming as 122.78.
>
> How come this possible. These regions are so far.
>
> ** **
>
> Here is my query. Can you please suggest me how can I get actual distance
> in meters here.
>
> ** **
>
> SELECT distance
>
> (st_geomfromtext('point(-123.574219125 47.8131546948944 0)', 900913),
>
> st_geomfromtext('LINESTRING(-0.791015625 48.4874864798841,9.4921875
> 54.5975278521139,27.59765625 55.3541353102106,36.38671875
> 48.3124279040718,22.32421875 40.3465441211801,5.888671875
> 43.8662180065564,-0.791015625 48.4874864798841)', 900913)
>
> )
>
> ** **
>
> Query returns 122.785055218779
>
> ** **
>
> What is significance of SRID here. Am I missing something?
>
> Which SRID should we use for general purpose.
>

This mailing list is for bugs in PostgreSQL; it sounds like you have a user
question about PostGIS.

I think this might be the right place:

http://postgis.refractions.net/mailman/listinfo/postgis-users

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[BUGS] CREATE ROLE jdbc vs pgadmin

[Flávio Alves Granato]

gentlemen,

I have a problem with the query 'CREATE ROLE' being executed via jdbc and
via pgadmin. When I run it via pgadmin:

CREATE ROLE flavio LOGIN
  ENCRYPTED PASSWORD 'cd6a0065e497a3c20b3c639df7d56b0d'
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

and via jdbc:

CREATE ROLE flavio LOGIN
  ENCRYPTED PASSWORD 'md5bf5a1a18f98fd6debde92560c933d2d9'
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

I did update to the newest jdbc:

CREATE ROLE flavio LOGIN
  ENCRYPTED PASSWORD 'md50eb617ecacedd0cfae723bbe53c75918'
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

 It would be a bug in jdbc? I am using PostgreSQL 9.1 and linux.

reguards,


Flávio Granato

Re: [BUGS] CREATE ROLE jdbc vs pgadmin

[John R Pierce]

On 11/17/11 11:56 AM, Flávio Alves Granato wrote:


I have a problem with the query 'CREATE ROLE' being executed via jdbc 
and via pgadmin. When I run it via pgadmin:


CREATE ROLE flavio LOGIN
  ENCRYPTED PASSWORD 'cd6a0065e497a3c20b3c639df7d56b0d'
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

and via jdbc:

CREATE ROLE flavio LOGIN
  ENCRYPTED PASSWORD 'md5bf5a1a18f98fd6debde92560c933d2d9'
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

I did update to the newest jdbc:

CREATE ROLE flavio LOGIN
  ENCRYPTED PASSWORD 'md50eb617ecacedd0cfae723bbe53c75918'
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

It would be a bug in jdbc? I am using PostgreSQL 9.1 and linux.


what is the problem?



--
john r pierceN 37, W 122
santa cruz ca mid-left coast



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] CREATE ROLE jdbc vs pgadmin

[Flávio Alves Granato]

2011/11/17 John R Pierce 

> On 11/17/11 11:56 AM, Flávio Alves Granato wrote:
>
>>
>> I have a problem with the query 'CREATE ROLE' being executed via jdbc and
>> via pgadmin. When I run it via pgadmin:
>>
>> CREATE ROLE flavio LOGIN
>>  ENCRYPTED PASSWORD '**cd6a0065e497a3c20b3c639df7d56b**0d'
>>  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
>>
>> and via jdbc:
>>
>> CREATE ROLE flavio LOGIN
>>  ENCRYPTED PASSWORD '**md5bf5a1a18f98fd6debde92560c93**3d2d9'
>>  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
>>
>> I did update to the newest jdbc:
>>
>> CREATE ROLE flavio LOGIN
>>  ENCRYPTED PASSWORD '**md50eb617ecacedd0cfae723bbe53c**75918'
>> NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
>>
>> It would be a bug in jdbc? I am using PostgreSQL 9.1 and linux.
>>
>
> what is the problem?
>
>
> sorry

the problem was me, that between the chair and keyboard, just generating a
hash of the password before creating the ROLE and login time did not
generate the hash of the password. Fix the code of my application and have
no more problem.

thank you,


Flavio

>
> --
> john r pierceN 37, W 122
> santa cruz ca mid-left coast
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-bugs
>

[BUGS] BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions

[lindebg]

The following bug has been logged online:

Bug reference:  6299
Logged by:  lindebg
Email address:  lind...@gmail.com
PostgreSQL version: 9.0, 9.1
Operating system:   Linux, Windows
Description:pg_dump, pg_dumpall - Problem with the order of backup
functions
Details: 

1. create database test and functions fn2, fn1:

$ psql -c "create database test"

$ psql test
test=# create function fn2()
returns int as
$$ select 1 $$
language sql immutable;

create function fn1(param1 int default fn2())
returns int as
$$ select $1 $$
language sql immutable;
\q



2. backup:

pg_dump -F c > test.backup



3. clear database:

psql -c "drop database test"
psql -c "create database test"



4. restore database:

pg_restore -d test test.backup


Errors:

pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 221; 1255 21043 FUNCTION
fn1(integer) postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  function fn2()
does not exist
LINE 1: CREATE FUNCTION fn1(param1 integer DEFAULT fn2()) RETURNS in...
   ^
HINT:  No function matches the given name and argument types. You might need
to add explicit type casts.
Command was: CREATE FUNCTION fn1(param1 integer DEFAULT fn2()) RETURNS
integer
LANGUAGE sql IMMUTABLE
AS $_$ select $1 $_$;



pg_restore: [archiver (db)] could not execute query: ERROR:  function
public.fn1(integer) does not exist
Command was: ALTER FUNCTION public.fn1(param1 integer) OWNER TO
postgres;


WARNING: errors ignored on restore: 2

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions

[Tom Lane]

"lindebg"  writes:
> Description:pg_dump, pg_dumpall - Problem with the order of backup
> functions

Yeah, this was reported last month --- CREATE FUNCTION neglects to mark
the function with the default expression as dependent on the other one.
It'll be fixed in the next set of update releases, or if you're in a big
hurry you can get the patch here:
http://archives.postgresql.org/pgsql-committers/2011-10/msg7.php

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs