headers
Markus Schaber | 1 Jul 2004 17:05
X-Face

Re: ERROR: permission denied for language c

Hi, Rudolf,

On Sun, 27 Jun 2004 15:16:22 -0700
Rudolf Nottrott <rnott <at> alexandria.UCSB.edu> wrote:

> $ createlang -U postgres  plpgsql testdb
> createlang: language installation failed:
> "ERROR:  permission denied for language c"

To create a language, you need the appropriate permissions (superuser
will do, ordinary user cannot, I'm not shure whether there's a special
create language permission...)

HTH,
markus

--

-- 
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios <at> logi-track.com | www.logi-track.com
Permalink | Reply | 0 comments |
headers
Jonathan Giorgio Ghellere | 2 Jul 2004 16:44
Picon

postgis+zaurus 5500

Hello,

I've compiled postgresql+postgis+proj for a zaurus 5500 running openzaurus 3.
3.5 and used qgis in a x86 machine to connect to the database in the zaurus.
The database was created using the http://postgis.refractions.net/docs/c206.
html:

CREATE TABLE gtest ( ID int4, NAME varchar(20) );
SELECT AddGeometryColumn('dbname','gtest','geom',-1,'LINESTRING',2);
INSERT INTO gtest (ID, NAME, GEOM) VALUES (1, 'First Geometry', 
GeometryFromText('LINESTRING(2 3,4 5,6 5,7 8)', -1));

Everything goes ok, but, when I use QGIS (http://qgis.org), to retrieve a 
feature map it returns a blank screen. So, I debug QGIS in order to see how it 
was selecting map and got something like this:

select oid,asbinary(geom,'NDR') as qgs_feature_geometry from gtest where geom 
&& GeometryFromText('BOX3D(        1.529391         2.750000,        7.470609  
       8.250000)'::box3d,-1);

In psql that query line returns:

  oid  |                                                                
qgs_feature_geometry
-------+----------------------------------------------------------------------
------------------------------------------------------------------------------
 21265 | 
010200000004000000000000400000000000000840000000000000104000000000000014400000
00000000184000000000000014400000000000001C40000000000000204000000000
(1 row)
(Continue reading)

Permalink | Reply | 4 comments |
headers
strk | 2 Jul 2004 17:06
Gravatar

Re: postgis+zaurus 5500

It seems postgis is not able to correctly detect BYTE_ORDER
on zaurus. Please check BYTE_ORDER and the like defines
in postgis_fn.c. Also try to find out where does your system
define that (if it does) or a architectur specific header defined
that could be handled for the specific case.
--strk;

On Fri, Jul 02, 2004 at 11:44:42AM -0300, Jonathan Giorgio Ghellere wrote:
> Hello,
> 
> I've compiled postgresql+postgis+proj for a zaurus 5500 running openzaurus 3.
> 3.5 and used qgis in a x86 machine to connect to the database in the zaurus.
> The database was created using the http://postgis.refractions.net/docs/c206.
> html:
> 
> CREATE TABLE gtest ( ID int4, NAME varchar(20) );
> SELECT AddGeometryColumn('dbname','gtest','geom',-1,'LINESTRING',2);
> INSERT INTO gtest (ID, NAME, GEOM) VALUES (1, 'First Geometry', 
> GeometryFromText('LINESTRING(2 3,4 5,6 5,7 8)', -1));
> 
> Everything goes ok, but, when I use QGIS (http://qgis.org), to retrieve a 
> feature map it returns a blank screen. So, I debug QGIS in order to see how it 
> was selecting map and got something like this:
> 
> select oid,asbinary(geom,'NDR') as qgs_feature_geometry from gtest where geom 
> && GeometryFromText('BOX3D(        1.529391         2.750000,        7.470609  
>        8.250000)'::box3d,-1);
> 
> In psql that query line returns:
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jonathan Giorgio Ghellere | 2 Jul 2004 22:59
Picon

Re: postgis+zaurus 5500

Hi,

I set BIG and LITTLE_ENDIAN and in both cases the problem persists.

In the BIG_ENDIAN, postgis return a XDR, and the select was a NDR..... a 
little crazy.

# select oid,asbinary(geom,'NDR') as qgs_feature_geometry from gtest where 
geom && GeometryFromText('BOX3D(        1.529391         2.750000,        7.
470609         8.250000)'::box3d,-1);

  oid  |                                                                
qgs_feature_geometry
-------+----------------------------------------------------------------------
------------------------------------------------------------------------------
 19203 | 
010000000200000004000000004000000000000000400800000000000040100000000000004014
00000000000040180000000000004014000000000000401C00000000000040200000
(1 row)

but is swapped too.

this is the endian.h of zaurus:

--------------------------cut---------------------
#ifndef _ENDIAN_H
#define _ENDIAN_H   1

#include <features.h>
/* Definitions for byte order, according to significance of bytes,
(Continue reading)

Permalink | Reply | 2 comments |
headers
strk | 3 Jul 2004 13:40
Gravatar

Re: postgis+zaurus 5500

On Fri, Jul 02, 2004 at 05:59:20PM -0300, Jonathan Giorgio Ghellere wrote:
> Hi,
> 
> I set BIG and LITTLE_ENDIAN and in both cases the problem persists.

Where did you set them ?
You should try setting under line 111 of postgis.h
Around there there is an inclusion of sys/param.h which 
has been found as needed for w32 systems.
I do not know about availability of the 'endian.h' include,
but including that would do the trick. As you can see
sys/param.h is included *only* for w32, if you can provide
a similar define for your system we can do the same thing.

--strk;

> 
> In the BIG_ENDIAN, postgis return a XDR, and the select was a NDR..... a 
> little crazy.
> 
> # select oid,asbinary(geom,'NDR') as qgs_feature_geometry from gtest where 
> geom && GeometryFromText('BOX3D(        1.529391         2.750000,        7.
> 470609         8.250000)'::box3d,-1);
> 
>   oid  |                                                                
> qgs_feature_geometry
> -------+----------------------------------------------------------------------
> ------------------------------------------------------------------------------
>  19203 | 
> 010000000200000004000000004000000000000000400800000000000040100000000000004014
(Continue reading)

Permalink | Reply | 1 comment |
headers
strk | 3 Jul 2004 13:44
Gravatar

Re: postgis+zaurus 5500

See on the matter:
http://postgis.refractions.net/pipermail/postgis-devel/2004-February/000125.html
And please check if postgresql endiannes detection fails.

--strk;

On Sat, Jul 03, 2004 at 01:40:38PM +0200, strk wrote:
> On Fri, Jul 02, 2004 at 05:59:20PM -0300, Jonathan Giorgio Ghellere wrote:
> > Hi,
> > 
> > I set BIG and LITTLE_ENDIAN and in both cases the problem persists.
> 
> Where did you set them ?
> You should try setting under line 111 of postgis.h
> Around there there is an inclusion of sys/param.h which 
> has been found as needed for w32 systems.
> I do not know about availability of the 'endian.h' include,
> but including that would do the trick. As you can see
> sys/param.h is included *only* for w32, if you can provide
> a similar define for your system we can do the same thing.
> 
> --strk;
> 
> > 
> > In the BIG_ENDIAN, postgis return a XDR, and the select was a NDR..... a 
> > little crazy.
> > 
> > # select oid,asbinary(geom,'NDR') as qgs_feature_geometry from gtest where 
> > geom && GeometryFromText('BOX3D(        1.529391         2.750000,        7.
> > 470609         8.250000)'::box3d,-1);
(Continue reading)

Permalink | Reply | 0 comments |
headers
christian.schuster | 3 Jul 2004 16:02
Picon

Christian Schuster/Rudolf Schuster AG is out of the office.


I will be out of the office starting  02.07.2004 and will not return until
12.07.2004.

Ferien Ferien Ferien

Ich werde am 12. July wieder zurück im Büro sein. Bis dann wünsche ich
allen ein frohes schaffen.

Gruss
Permalink | Reply | 0 comments |
headers
Andrea Aime | 4 Jul 2004 23:18
Picon

jdbc, bytea for the write side

Hi everybody,
a simple question: it is just me, or we have a function that converts wkb to 
bytea but not the other way round? Using bytea(AsBinary(...,...)) in jdbc 
reads I've got a nice performance improvement, so I was wondering if I could
an improvement on the write side too (althought I'm aware I won't get much
due to the lack or real batch statements support in the current stable jdbc 
driver). 
So, is there a way to create a statements like "insert into table(geom) 
values(GeomFromWKB(bytea2wkb(?)))" and then perform a direct setBytes(xxx)
on the prepared statement? I assume we lack a function to convert from bytea 
to wkb, but I don't know well postgis internals...

Best regards
Andrea Aime
Permalink | Reply | 3 comments |
headers
David Blasby | 5 Jul 2004 05:22
Picon

Re: jdbc, bytea for the write side

ByteA is binary compatible with the postgis type, so you should just
be able to create a "binary compatible" 'NULL' cast for it.

I think something like "CREATE CAST (BYTEA AS
WKB)   WITHOUT FUNCTION AS IMPLICIT ;" should do the trick.

This is only available in recent postgresql versions.

You can do it in older versions easily, too.

Unfortunately, I'm no longer working at Refractions and I havent got a
system setup at home yet; I'm unable to test.

I believe you can (as funny as it sounds), use the "WKBtoBYTEA"
function since its a do-nothing function.

CREATE FUNCTION wkb(bytea)
       RETURNS geometry
       AS ' <at> MODULE_FILENAME <at> ','WKBtoBYTEA'
       LANGUAGE 'C' WITH (iscachable,isstrict);

So instead of using "bytea2wkb()" you can use "wkb(<bytea>)".

If this works, have strk commit the change.

Have you checked to see whats actually being sent between geotools and
Postgis?  If I remember the SQL standard, bytea is sent as strings
like '0001001001000111001' - you could be sending 8* as much data as
you're expecting.  (This is assuming a text, NOT binary, cursor).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrea Aime | 5 Jul 2004 08:16
Picon

Re: jdbc, bytea for the write side

Alle 05:22, lunedì 5 luglio 2004, David Blasby ha scritto:
> ByteA is binary compatible with the postgis type, so you should just
> be able to create a "binary compatible" 'NULL' cast for it.
>
> I think something like "CREATE CAST (BYTEA AS
> WKB)   WITHOUT FUNCTION AS IMPLICIT ;" should do the trick.
>
> This is only available in recent postgresql versions.
>
> You can do it in older versions easily, too.
>
> Unfortunately, I'm no longer working at Refractions and I havent got a
> system setup at home yet; I'm unable to test.
>
> I believe you can (as funny as it sounds), use the "WKBtoBYTEA"
> function since its a do-nothing function.
>
> CREATE FUNCTION wkb(bytea)
>        RETURNS geometry
>        AS ' <at> MODULE_FILENAME <at> ','WKBtoBYTEA'
>        LANGUAGE 'C' WITH (iscachable,isstrict);
>
> So instead of using "bytea2wkb()" you can use "wkb(<bytea>)".

Thank you, I'll try it out

> If this works, have strk commit the change.
>
> Have you checked to see whats actually being sent between geotools and
> Postgis?  If I remember the SQL standard, bytea is sent as strings
(Continue reading)

Permalink | Reply | 1 comment |

Gmane