Komisches Ergebnis in WHERE .... Denkfehler ?

Tach zusammen, ich sitze moeglicherweise einem ganz dummen Denkfehler
auf, erkenne ihn aber offenbar selbst mit Nachdenken nicht. Eigentlich
handelt es sich um eine der einfachsten Aufgaben, die so eine Datenbank
ueberhaupt kennt .... :-/
Der 'Kandidat' ist eine PostgreSQL/PostGIS-Datenbank. Diese haben
naturgemaess alle eine Tabelle "geometry_columns", in der diejenigen
Tabellen gelistet sind, die so eingerichtet sind, dass sie Geodaten
speichern koennen (das ist etwas vereinfacht, aber dennoch zutreffend).

Ich will mir nun diejenigen Tabellen listen lassen, deren Name mit
"clc" und anschliessend einem Unterstrich beginnt:

landcover=> \d geometry_columns
Table "public.geometry_columns"
Column | Type | Modifiers
-------------------+------------------------+-----------
f_table_catalog | character varying(256) | not null
f_table_schema | character varying(256) | not null
f_table_name | character varying(256) | not null
f_geometry_column | character varying(256) | not null
coord_dimension | integer | not null
srid | integer | not null
type | character varying(30) | not null
Indexes:
"geometry_columns_pk" PRIMARY KEY, btree (f_table_catalog, f_table_schema, f_table_name, f_geometry_column)

landcover=> SELECT f_table_name FROM geometry_columns WHERE f_table_name LIKE 'clc_%';
f_table_name
--------------------------
clc06_fr_urban
[...]


Mein erster Gedanke war: "Da ist doch 'was kaputt" - zumal ich in
Vergangenheit auf solche Selektionen quasi blind vertraut habe. Ich
will aber gerne in Betracht ziehen, dass ich einfach 'was falsch mache,
die sprichwoertlichen Tomaten auf den Augen habe. Hilft mir jemand ?

Der Vollstaendigkeit halber, auch wenn's hier vermutlich gar nicht von
Belang ist:
Der Server laeuft auf einem 64-bittigen Solaris10, der Client auf einem
64-bittigen Linux, beide auf Intel-Hardware, beide in Version 9.0.1,
nach alter Tradition gebraut .... selbst uebersetzt.

Dankeschoen,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
------------------------------------------------------------ --------------

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

Re: Komisches Ergebnis in WHERE .... Denkfehler?

On 11/22/10 3:24 PM, Martin Spott wrote:
> Tach zusammen, ich sitze moeglicherweise einem ganz dummen Denkfehler
> auf, erkenne ihn aber offenbar selbst mit Nachdenken nicht. Eigentlich
> handelt es sich um eine der einfachsten Aufgaben, die so eine Datenbank
> ueberhaupt kennt .... :-/
> Der 'Kandidat' ist eine PostgreSQL/PostGIS-Datenbank. Diese haben
> naturgemaess alle eine Tabelle "geometry_columns", in der diejenigen
> Tabellen gelistet sind, die so eingerichtet sind, dass sie Geodaten
> speichern koennen (das ist etwas vereinfacht, aber dennoch zutreffend).
>
> Ich will mir nun diejenigen Tabellen listen lassen, deren Name mit
> "clc" und anschliessend einem Unterstrich beginnt:
>
> landcover=> \d geometry_columns
> Table "public.geometry_columns"
> Column | Type | Modifiers
> -------------------+------------------------+-----------
> f_table_catalog | character varying(256) | not null
> f_table_schema | character varying(256) | not null
> f_table_name | character varying(256) | not null
> f_geometry_column | character varying(256) | not null
> coord_dimension | integer | not null
> srid | integer | not null
> type | character varying(30) | not null
> Indexes:
> "geometry_columns_pk" PRIMARY KEY, btree (f_table_catalog, f_table_schema, f_table_name, f_geometry_column)
>
> landcover=> SELECT f_table_name FROM geometry_columns WHERE f_table_name LIKE 'clc_%';
> f_table_name
> --------------------------
> clc06_fr_urban
> [...]
>

Moin,
ich hab es selbst nicht ausprobiert, aber das Manual von 9.0 sagt, dass
ein '_' in der LIKE Anweisung auf ein beliebiges Zeichen matcht:

An underscore (_) in pattern stands for (matches) any single character;
a percent sign (%) matches any sequence of zero or more characters. (aus
http://www.postgresql.org/docs/9.0/interactive/functions-mat ching.html).

d.h. clc0 matcht auf clc_ aus dem LIKE und der Rest kommt vom '%'

HTH,
Hubertus

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

Re: Komisches Ergebnis in WHERE .... Denkfehler ?

Am 22. November 2010 15:24 schrieb Martin Spott :

> Ich will mir nun diejenigen Tabellen listen lassen, deren Name mit
> "clc" und anschliessend einem Unterstrich beginnt:

[..]

> landcover=3D> SELECT f_table_name FROM geometry_columns WHERE f_table_nam=
e LIKE 'clc_%';
>       f_table_name
> --------------------------
>  clc06_fr_urban

Der unterstrich hat eine besondere bedeutung in LIKE-mustern:

TIONS-LIKE>

Nicolas

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

Re: Komisches Ergebnis in WHERE .... Denkfehler ?

Nicolas Barbier wrote:
> Am 22. November 2010 15:24 schrieb Martin Spott >:

>> Ich will mir nun diejenigen Tabellen listen lassen, deren Name mit
>> "clc" und anschliessend einem Unterstrich beginnt:
>=20
> [..]
>=20
>> landcover=3D> SELECT f_table_name FROM geometry_columns WHERE f_table_=
name LIKE 'clc_%';
>> =A0 =A0 =A0 f_table_name
>> --------------------------
>> =A0clc06_fr_urban
>=20
> Der unterstrich hat eine besondere bedeutung in LIKE-mustern:
>=20
> FUNCTIONS-LIKE>

Ich werd' zum Elch !! - klar, mit zwei Backslashes davor tut's das ganz
wunderbar. Erstaunlich, dass mir das nicht schon viel frueher um die
Ohren geflogen ist ....

Besten Dank,
Martin.
--=20
Unix _IS_ user friendly - it's just selective about who its friends are =
!
------------------------------------------------------------ -------------=
-

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein