[Gdal-dev] ogr2ogr segfaults with large SQL statement

[Bruce Raup]

Hi Frank,

On 4/4/06, Frank Warmerdam <warmerdam at pobox.com> wrote:

> I'm not too sure what version 1.6 is.  Perhaps 1.2.6 of GDAL?

I got that number from the libgdal file:  "libgdal.so.1.6.0", which I
built and installed on 2005-02-28.


> My understanding of the current logic is that it should list all
> tables and views that have geometry columns in the list of named
> layers.  The current query for layers looks like:
>
> SELECT c.relname FROM pg_class c, geometry_columns g
>     WHERE (c.relkind in ('r','v') AND c.relname !~ '^pg'
>     AND c.relname::TEXT = g.f_table_name::TEXT)
>
> Hmm, I see the documentation claims views are not supported.  Just
> how does one go about creating a named view in Postgres?

Not supported in what?  PostgreSQL?  Views are definitely supported in
PostgreSQL.  In psql, "\h create" gives (among other things):

Command:     CREATE VIEW
Description: define a new view
Syntax:
CREATE [ OR REPLACE ] VIEW name [ ( column_name [, ...] ) ] AS query

Or are you talking about ogr2ogr not supporting views?  The old
version (our "1.6") did indeed work for querying PostgreSQL (PostGIS)
views.

> I was going to suggest you use the special datasource syntax
> for listing explicit tables but I see that isn't supported for
> postgres.  Perhaps I need to add it.

I don't follow.  This is a special syntax for ogr2ogr?

>
> > - If the WHERE clause in the SQL statement exceeds around 5000
> > characters, it still segfaults.
>
> I have added a test for large attribute filters, and for large
> SQL statements to the test suite, and identified a serious bug
> which I have corrected.  Large attribute filters should now work
> with OGR CVS.

Great!  By "large", what do you mean?  Is there still a hard limit? 
Or does it use a dynamically allocated buffer?

Continued thanks,
Bruce

--
Bruce Raup
http://cires.colorado.edu/~braup/