CREATE OPERATOR Tutorial

Fragen und Probleme rund um die Abfragespache SQL.

CREATE OPERATOR Tutorial

Beitragvon symbiont » Do 5. Jun 2008, 09:56

Also hier die Frage in Anlehnung zu
http://www.pg-forum.de/sql/2453-user-defined-komplexe-typen.html#post12451

Nehmen wir an ich habe einen Neuen Typ point (nur als Beispiel) mit
CREATE TYPE point AS
(x integer,
y integer);

erzeugt. Nun existieren für diesen Typen ja noch keine Operatoren, mit denen ich den Werte des Typs vergleichen könnte, oder diesen Sortieren dürfte. Wen nich mir die Operatoren im Lieferumfang von PG anschaue, dann sehe ich, dass diese verständlicher Weise alle auf eine eigene PROCEDURE verweisen. Ich nehme also an, ich muss nun auch für meinen Typ und jeden Operator eine PROCEDURE implementieren? Gibt es standard-Prozeduren die mit jedem Typ als Text umgehen können? Wie gehe ich da am besten ran ..

Gruß
symbiont
Erfahrener Benutzer
 
Beiträge: 1328
Registriert: Mo 17. Mär 2008, 12:45
Wohnort: NULL

Beitragvon akretschmer » Do 5. Jun 2008, 10:08

symbiont hat geschrieben:Also hier die Frage in Anlehnung zu
http://www.pg-forum.de/sql/2453-user-defined-komplexe-typen.html#post12451

Nehmen wir an ich habe einen Neuen Typ point (nur als Beispiel) mit
CREATE TYPE point AS
(x integer,
y integer);

erzeugt. Nun existieren für diesen Typen ja noch keine Operatoren, mit denen ich den Werte des Typs vergleichen könnte, oder diesen Sortieren dürfte. Wen nich mir die Operatoren im Lieferumfang von PG anschaue, dann sehe ich, dass diese verständlicher Weise alle auf eine eigene PROCEDURE verweisen. Ich nehme also an, ich muss nun auch für meinen Typ und jeden Operator eine PROCEDURE implementieren?

Absolut korrekt.

Wie gehe ich da am besten ran ..


Handbuch lesen.
- PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: User-Defined Types
- PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: User-Defined Operators
- PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: Operator Optimization Information

Andreas
--
ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)

https://www.xing.com/profile/Andreas_Kretschmer7
Hosting-Provider mit PostgreSQL-Support gesucht? Mich fragen!
akretschmer
Erfahrener Benutzer
 
Beiträge: 5938
Registriert: So 29. Okt 2006, 14:35
Wohnort: Kaufbach, Sachsen, Germany, Germany

Beitragvon symbiont » Do 5. Jun 2008, 10:23

akretschmer hat geschrieben:Absolut korrekt.
Handbuch lesen.
- PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: User-Defined Types

den Artikel kannte ich schon ..


den habe ich gesucht .. da war ja ein Hinweiss im obigen, dass da irgendsoeiner Existiert ...

Es scheint tatsächlich so, dass man mit user-defined types nicht wirklich arbeiten kann, wenn man nicht anfangen möchte libraries z.B. in C zu schreiben, welche den Operator implementieren ?

Welchen Sinn machen dann die einfachen user-defined types - also einfache composite types wie mein point ?. Irgendwie gehen diese Artikel garnicht darauf ein - sie demonstrieren nur den leidlichen Weg wenn man mit externen Routinen arbeiten möchte. Nun das möchte ich ausdrücklich nicht - weil mir das niemand bezahlt und ich soviel Leidenschaft meienm Auftraggeber auch nicht rechtfertigen kann. Zudem möchte ich ja ähnliches auch mit ORACLE bzw. MsSQL usw. erreichen können.

Kann ich also davon ausgehen, dass einfache composite types für die Katz sind, wenn man nach solchen auch sortieren oder einfach nur vergleichen möchte?


Das Anliegen der Optimierung habe ich verstanden .. abe soweit sind wir noch nicht :)

Gruß
symbiont
Erfahrener Benutzer
 
Beiträge: 1328
Registriert: Mo 17. Mär 2008, 12:45
Wohnort: NULL

Beitragvon akretschmer » Do 5. Jun 2008, 10:32

symbiont hat geschrieben:[/URL]


Es scheint tatsächlich so, dass man mit user-defined types nicht wirklich arbeiten kann, wenn man nicht anfangen möchte libraries z.B. in C zu schreiben, welche den Operator implementieren ?

Das kann man durchaus so interpretieren.

Welchen Sinn machen dann die einfachen user-defined types - also einfache composite types wie mein point ?. Irgendwie gehen diese Artikel garnicht darauf ein - sie demonstrieren nur den leidlichen Weg wenn man mit externen Routinen arbeiten möchte. Nun das möchte ich ausdrücklich nicht - weil mir das niemand bezahlt und ich soviel Leidenschaft meienm Auftraggeber auch nicht rechtfertigen kann. Zudem möchte ich ja ähnliches auch mit ORACLE bzw. MsSQL usw. erreichen können.

So wie PG nicht erraten kann, welche von 2 Variablen eines selbst definierten Typs (bestehend aus 2 INT, 3 FLOAT und 1 TEXT als Beispiel) größer als der andere ist bezweifle ich, daß ORA oder M$SQL diese hellseherische Gabe besitzen. Insofern läuft Dein Rant also ins Leere.

Kann ich also davon ausgehen, dass einfache composite types für die Katz sind, wenn man nach solchen auch sortieren oder einfach nur vergleichen möchte?


Wie ich schon sagte: wenn Du damit Deine Anwendung besser auf PG abbilden kannst, steht Dir dieser Weg offen. PG bietet halt die passenden Schnittstellen für solche Erweiterungen. PostGIS z.B. lebt davon und ist in der Welt der GIS-Datenbanken wohl wahrlich nicht die schlechteste Wahl.

Andreas
--
ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)

https://www.xing.com/profile/Andreas_Kretschmer7
Hosting-Provider mit PostgreSQL-Support gesucht? Mich fragen!
akretschmer
Erfahrener Benutzer
 
Beiträge: 5938
Registriert: So 29. Okt 2006, 14:35
Wohnort: Kaufbach, Sachsen, Germany, Germany

Ws gibt immer einen naheliegenden Weg,

Beitragvon symbiont » Do 5. Jun 2008, 10:35

Der i.d.R. nicht falsch sein kann
== alle Felder gleich
< Felder "der Reihe nach" - wie definiert auf kleiner prüfen, so wie man sie ganz gewöhnlich vergleichen würde
> analaog wie auch >= usw.
danach koennte man dann auch indizieren ..

und wenn mir das naheliegende nicht gefällt, kann ich mich immernoch darüber freuen, dass PG schnittstellen hat.

Das hat alles nichts mit raten zu tun.

Gruß

akretschmer hat geschrieben:Das kann man durchaus so interpretieren.


So wie PG nicht erraten kann, welche von 2 Variablen eines selbst definierten Typs (bestehend aus 2 INT, 3 FLOAT und 1 TEXT als Beispiel) größer als der andere ist bezweifle ich, daß ORA oder M$SQL diese hellseherische Gabe besitzen. Insofern läuft Dein Rant also ins Leere.



Wie ich schon sagte: wenn Du damit Deine Anwendung besser auf PG abbilden kannst, steht Dir dieser Weg offen. PG bietet halt die passenden Schnittstellen für solche Erweiterungen. PostGIS z.B. lebt davon und ist in der Welt der GIS-Datenbanken wohl wahrlich nicht die schlechteste Wahl.

Andreas
symbiont
Erfahrener Benutzer
 
Beiträge: 1328
Registriert: Mo 17. Mär 2008, 12:45
Wohnort: NULL

Beitragvon akretschmer » Do 5. Jun 2008, 10:47

symbiont hat geschrieben:Der i.d.R. nicht falsch sein kann
== alle Felder gleich
< Felder "der Reihe nach" - wie definiert auf kleiner prüfen, so wie man sie ganz gewöhnlich vergleichen würde
> analaog wie auch >= usw.

Nicht immer ist naheliegend auch richtig. Naheliegende Beispiele zu erfinden erspare ich mir aber.

danach koennte man dann auch indizieren ..

Index-Operationen sind noch einmal eine Klasse für sich mit einer extra Schnittstelle:
PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: Interfacing Extensions To Indexes

Andreas
--
ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)

https://www.xing.com/profile/Andreas_Kretschmer7
Hosting-Provider mit PostgreSQL-Support gesucht? Mich fragen!
akretschmer
Erfahrener Benutzer
 
Beiträge: 5938
Registriert: So 29. Okt 2006, 14:35
Wohnort: Kaufbach, Sachsen, Germany, Germany

Ein Standardverhalten

Beitragvon symbiont » Do 5. Jun 2008, 10:56

hat sicherlich nichts mit erfinden zu tun. Es ist reine Definitionssache. Schön ist es eben, wenn die Definition der Intuition entspricht - das macht eine gute Definition aus.

Naja die ganze Debatte bringt nichts - da sowas eh nicht vorgesehen ist - in MsSQL auch nicht .. ich muss mir nun überlegen wie ich mit diesem Thema überhaupt umgehen sollte. Wahrscheinlich canceln .. ich bin eben ein wenig enttäuscht, dass es sich gleich so aufwendig darstellen muss.

Tjaja .. und indizes darauf kann ich auch gleich knicken .. ich denke ich werde komplexe Typen in meiner middleware unterstützen .. für die handvoll Typen die ich so vor mir sehe werde ich mir dann ne geeignete Repräsentation in irgendeinem Basistypen ausdenken .. das versteht auch jeder der es sieht. Die Notwendigkeit solcher Schnittstellen sehe ich durchaus - nur für mich ist das mit Kanonen auf Sperlinge geworfen.

Gruß
symbiont
Erfahrener Benutzer
 
Beiträge: 1328
Registriert: Mo 17. Mär 2008, 12:45
Wohnort: NULL

Beitragvon ads » Do 5. Jun 2008, 13:19

symbiont hat geschrieben:Es scheint tatsächlich so, dass man mit user-defined types nicht wirklich arbeiten kann, wenn man nicht anfangen möchte libraries z.B. in C zu schreiben, welche den Operator implementieren ?

Das stimmt nicht. Du kannst deine Funktionen in jeder beliebigen unterstützten Sprache schreiben.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support
ads
Erfahrener Benutzer
 
Beiträge: 4147
Registriert: Mi 8. Feb 2006, 11:58
Wohnort: MD

Beitragvon akretschmer » Do 5. Jun 2008, 13:29

ads hat geschrieben:Das stimmt nicht. Du kannst deine Funktionen in jeder beliebigen unterstützten Sprache schreiben.


Er schrieb "z.B.".

Andreas
--
ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)

https://www.xing.com/profile/Andreas_Kretschmer7
Hosting-Provider mit PostgreSQL-Support gesucht? Mich fragen!
akretschmer
Erfahrener Benutzer
 
Beiträge: 5938
Registriert: So 29. Okt 2006, 14:35
Wohnort: Kaufbach, Sachsen, Germany, Germany


Zurück zu SQL

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron