Hallo.
In MySQL 5.0.18 soll untenstehende Funktion eigentlich UNSIGEND
ZEROFILL zurückgeben. Es kommt aber nur der Integer-Wert zurück - ohne
führende Nullen.
Warum?
Peter
CREATE FUNCTION barcode8(barcode11 BIGINT(11))
RETURNS INT(8) UNSIGNED ZEROFILL
BEGIN
RETURN RIGHT(barcode11, 8);
END;
Am 28.08.2007 10:18 schrieb petsch:
> Hallo.
>
> In MySQL 5.0.18 soll untenstehende Funktion eigentlich UNSIGEND
> ZEROFILL zurückgeben. Es kommt aber nur der Integer-Wert zurück - ohne
> führende Nullen.
>
> Warum?
>
> Peter
>
>
> CREATE FUNCTION barcode8(barcode11 BIGINT(11))
> RETURNS INT(8) UNSIGNED ZEROFILL
>
> BEGIN
> RETURN RIGHT(barcode11, 8);
> END;
>
Ich fürchte, ZEROFILL ergibt in diesem Zusammenhang keinen Sinn. Die
Dokumentation bei dev.mysql.com/doc ist da nicht besonders klar, aber
in meinem Verständnis ist ZEROFILL etwas, das nur bei der (ggfs.
impliziten) Umwandlung eines numerischen Werts in seine
Stringrepräsentation berücksichtigt wird. Wenn Du eine Stored
Procedure/Function mit numerischen Parameter bzw. Rückgabewerten
verwendest, dann bekommst Du eben immer einen numerischen Wert -
keinen String. Führende Nullen haben in einem Integer keine Bedeutung.
Was Du da machst, ist m.E. mutig, aber nicht zielführend. Du übergibst
einen INT und willst dessen 8 letzte Stellen haben, Dazu lässt Du ihn
von MySQL *implizit* in einen CHAR(11) wandeln (wobei sicherlich gar
keine führenden Nullen entstehen) und aus diesem String soll MySQL
dann wieder implizit einen INT machen, den Du aber wie durch
Zauberkraft in einen STRING mit führenden Nullen sehen willst.
Ich habe keine Ahnung (und auch keine Lust, zu suchen), ob MySQL
passende Funktionen für das Gewünschte bietet. Wenn nicht, schreib die
Funktion halt selbst. Das sollte mit ein bisschen Division durch 10,
CONCAT() etc. leicht zu machen sein.
--
Christian
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Am 28.08.2007 11:34 schrieb petsch:
>
> Die direkte Abfrage einer Spalte vom Typ INT UNSIGNED ZEROFILL liefert
> mir ja auch die führenden Nullen mit. Genau das erwarte ich also auch
> von einer stored function der ich explizit mitteile, ZEROFILL zu
> liefern.
Schreib einen Bug-Report.
--
Christian
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Am 28.08.2007 12:26 schrieb petsch:
> On 28 Aug., 12:17, Andreas Kretschmer
> wrote:
>> Dann laß Dir einen STRING liefern, wenn Du einen willst, und keinen INT.
>
> Nööö. Ich will ja einen INT. Zwecks JOIN mit einem UNSIGNED ZEROFILL
> einer anderen Tabelle. Dann werde ich lieber mit php den Integer bei
> der Ausgabe mit Nullen auffüllen. Zumindest bis MySQL den Bug gefixt
> hat.
>
Das hört sich wirklich nach einem überzeugenden und durchdachten
Konzept an: Ints vorne mit Nullen auffüllen, damit man sie JOINen kann.
Du bist ganz sicher, dass Du diesen ganzen Schandudel *brauchst*, um
zwei INT in einem JOIN benutzen zu können?
--
Christian
On 28 Aug., 12:38, Christian Kirsch
>
> Das hört sich wirklich nach einem überzeugenden und durchdachten
> Konzept an: Ints vorne mit Nullen auffüllen, damit man sie JOINen kann.
Du bist dem Thread nicht richtig gefolgt.
Ich brauche natürlich den *INT* für den den JOIN, nicht die *Nullen*.
Der Rückgabewert der Funktion wird mit einer INT-Spalte gejoint (siehe
oben)
Die Nullen sind nur für die bequemere Ausgabe: Umwandlung in einen
3of9-Barcode
>
> Du bist ganz sicher, dass Du diesen ganzen Schandudel *brauchst*, um
> zwei INT in einem JOIN benutzen zu können?
Erst lesen, dann posten, dann ..... :-) SCNR
Peter
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
petsch
> On 28 Aug., 12:17, Andreas Kretschmer
> wrote:
>>
>> Dann laß Dir einen STRING liefern, wenn Du einen willst, und keinen INT.
>
> Nööö. Ich will ja einen INT. Zwecks JOIN mit einem UNSIGNED ZEROFILL
> einer anderen Tabelle.
LOL. Wenn du auch nur ein Minimum an Performance willst, solltest du
JOINs *niemals* gegen berechnete Spalten machen. Insbesondere bei
deiner Funktion ist das sinnlos, weil Integer-Vergleiche sowas wie
führende Nullen ohnehin nicht kennen.
Die korrekte Variante wäre also, eine Funktion rein zur Formatierung
der Ausgabe zu schreiben. Und die kann/soll dann einen String liefern.
> Dann werde ich lieber mit php den Integer bei
> der Ausgabe mit Nullen auffüllen. Zumindest bis MySQL den Bug gefixt
> hat.
Ich sehe deinen Bugreport nicht. Keine Arme, keine Kekse!
XL
Axel Schwenke schrieb:
>
> [...] weil Integer-Vergleiche sowas wie
> führende Nullen ohnehin nicht kennen.
Keine Ahnung wie oft ich das noch erzählen muss: Ich brauche die
Nullen *NICHT* für den JOIN.
>
> Ich sehe deinen Bugreport nicht. Keine Arme, keine Kekse!
Weder Bock noch Zeit. Vermutlich stürzt sich eh' nur die
"It's-not-a-Bug-it's-a-feature" Fraktion dieser Gruppe drauf, um zu
erklären, dass es in MySQL keine Bugs gibt. Weil nicht sein kann, was
nicht sein darf.
Peter
Peter Schleif schrieb:
> Axel Schwenke schrieb:
>> [...] weil Integer-Vergleiche sowas wie
>> führende Nullen ohnehin nicht kennen.
>
> Keine Ahnung wie oft ich das noch erzählen muss: Ich brauche die
> Nullen *NICHT* für den JOIN.
>
Dann les' ich Dir mal Dich selber vor:
> Nööö. Ich will ja einen INT. Zwecks JOIN mit einem UNSIGNED ZEROFILL
> einer anderen Tabelle.
>> Ich sehe deinen Bugreport nicht. Keine Arme, keine Kekse!
>
> Weder Bock noch Zeit. Vermutlich stürzt sich eh' nur die
> "It's-not-a-Bug-it's-a-feature" Fraktion dieser Gruppe drauf, um zu
> erklären, dass es in MySQL keine Bugs gibt. Weil nicht sein kann, was
> nicht sein darf.
Dann les' ich Dir mal mich vor:
> Schreib einen Bug-Report.
Allerdings denke ich tatsächlich, dass eine Funktion die man "nicht für
einen JOIN braucht" sondern nur für die formatierte Ausgabe von
irgendwas(tm), einen STRING zurückliefern muss.
Christian Kirsch schrieb:
>
> Dann les' ich Dir mal Dich selber vor:
>
>> Nööö. Ich will ja einen INT. Zwecks JOIN mit einem UNSIGNED ZEROFILL
>> einer anderen Tabelle.
Und?
Ein UNSIGNED ZEROFILL ist nun mal automatisch ein INT und somit
legitimes Ziel meines Joins.
Was Du immer noch nicht kapiert hast: Ich will zwei Fliegen mit einer
Klappe erschlagen:
1. INT (für den JOIN auf ein INT)
2. ZEROFILL für die Ausgabe.
Die Tabelle liefert das. Die stored function nicht!!!
Butter bei die Fische:
-------------------------
Zeigt mit den Code der meine Vorgaben (in 5.0.18) erfüllt und ich
entschuldige mich bei der ganzen NG und allen MySQL-Entwicklern für
die folgende Unterstellung:
MySQL beherrscht in 5.0.18 keine FUNCTIONS die einen übergebenen
UNSIGNED ZEROFILL gemäß meinen Vorgaben verarbeiten und UNSIGNED
ZEROFILL als Rückgabewert liefern.
Das ist meine Behauptung. Widerlegt sie, wenn ihr könnt.
Peter
Peter Schleif schrieb:
> MySQL beherrscht in 5.0.18 keine FUNCTIONS die einen übergebenen
> UNSIGNED ZEROFILL gemäß meinen Vorgaben verarbeiten und UNSIGNED
> ZEROFILL als Rückgabewert liefern.
>
> Das ist meine Behauptung. Widerlegt sie, wenn ihr könnt.
>
Wozu? Mich interessiert das nicht. Du stehst hier rum, stampfst mit dem
Fuß auf und rufst "ich will aber". Ich habe Dir schon gesagt, was ich
für sinnvoll halte.
Schreib einen Bugreport.
Christian Kirsch schrieb:
>
> Wozu? Mich interessiert das nicht.
Feigling!
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
Andreas Kretschmer schrieb:
>
> Lernresistenter Idiot.
Feigling!
Andreas Kretschmer wrote:
> Dann laà Dir einen STRING liefern, wenn Du einen willst, und keinen INT.
Er will aber weder einen String noch einen INT, sondern einen
*INT UNSIGNED ZEROFILL* - und es gibt eigentlich keinen vernünftigen
Grund das _nicht_ zu wollen, denn dieser Datentyp entspricht genau dem
was gewünscht ist. Es ist eben ein INT, der bei der Ausgabe mit
führenden Nullen gedruckt wird.
MySQL kann das anscheinend nicht, also: Bugreport schreiben. :)
GruÃ,
Michael
--
Testscript für RegEchsen:
http://diesundas.funzt-halt.net/regextest.php
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
On 2007-08-28, Andreas Kretschmer
>
> Selbst als MySQL-Hasser, als der ich hier bekannt bin, sehe ich nicht
> wirklich einen Bug. Echt.
>
> Im übrigen sehe ich *keinerlei* Grund für einen solch obskuren Datentyp
> wie *INT UNSIGNED ZEROFILL*. Hier scheint man bei MySQL fehlende
> Features wie generate_series() oder ein gescheites, kostenbasiertes
> EXPLAIN durch sinnfreie Konstrukte zu kaschieren. Aber das kennt man ja
> mittlerweile...
Aber Du hast es ja dann doch wieder geschafft, die Kurve zum MySQL-
Bashing zu bekommen. Fast, aber nur fast, hättest Du mich überrascht.
Aber was hat ZEROFILL mit generate_series() oder EXPLAIN zu tun?
Grüße,
Florian
Andreas Kretschmer wrote:
> Mag sein, das dieser Rat sinnvoll erscheinen mag. Ein numerischer Wert,
> der N Nullen vorweg führt, ist es aber nicht. Ich bin mir grad nicht
> sicher, in welcher Klasse ich das lernte, ist lange her, aber 007 ist
> dasselbe wie 07 ist dasselbe wie 7. [...]
Ack. Daher will der OP ja keinen String, damit MySQL mit dem Ding noch
*rechnet* wie mit einem normalen int. Erst bei der *Ausgabe* sollen dann
die Nullen davor geschrieben werden.
Ob das jetzt mit einem speziell dafür vorgesehenen Datentyp realisiert
wird oder mittels anderer Funktionen sei mal dahingestellt. Es ist aber
irgendwie unsinnig, einen Datentyp bei Feldern verfügbar zu machen, den
man aber nirgendwo sonst benutzen kann - z.b. bei Stored Procedures.
Genau das ist hier geschehen, und das sollte seitens MySQL-AB geändert
werden.
> Im übrigen sehe ich *keinerlei* Grund für einen solch obskuren Datentyp
> wie *INT UNSIGNED ZEROFILL*. Hier scheint man bei MySQL fehlende
> Features wie generate_series() oder ein gescheites, kostenbasiertes
> EXPLAIN durch sinnfreie Konstrukte zu kaschieren. Aber das kennt man ja
> mittlerweile...
Stimmt, es gibt dafür andere Methoden, die mit Blick auf diese Probleme
vielleicht sinnvoller sind als ein IUZ, besonders wenn man bedenkt dass
spätestens die MySQL-Client-Lib letztendlich die Zahl sowieso in einen
String (bzw. Char-Array) konvertiert. Daher halte ich es auch für das
sinnvollste, solche Fakes wie IUZ zu vermeiden und Nullen an der Stelle
einzufügen wo man sie will - nämlich in dem Code der die Ausgabe erzeugt.
GruÃ,
Michael
--
Testscript für RegEchsen:
http://diesundas.funzt-halt.net/regextest.php
Peter Schleif
> Christian Kirsch schrieb:
>>
>> Dann les' ich Dir mal Dich selber vor:
>>
>>> Nööö. Ich will ja einen INT. Zwecks JOIN mit einem UNSIGNED ZEROFILL
>>> einer anderen Tabelle.
>
> Und?
Wenn du den Widerspruch nicht siehst, kann ich dir auch nicht helfen.
> Butter bei die Fische:
> -------------------------
>
> Zeigt mit den Code der meine Vorgaben (in 5.0.18) erfüllt und ich
> entschuldige mich bei der ganzen NG und allen MySQL-Entwicklern für
> die folgende Unterstellung:
>
> MySQL beherrscht in 5.0.18 keine FUNCTIONS die einen übergebenen
> UNSIGNED ZEROFILL gemäß meinen Vorgaben verarbeiten und UNSIGNED
> ZEROFILL als Rückgabewert liefern.
>
> Das ist meine Behauptung. Widerlegt sie, wenn ihr könnt.
Das sind zwei verschiedene Dinge:
1. Anscheinend können stored Functions keinen INT(n) ZEROFILL zurück
liefern. Das ist IMNSHO ein Bug.
2. SELECT formatiert(foo), ...
FROM bar JOIN baz ON (bar.foo = baz.sabbel)
WHERE ...
macht den JOIN gegen die unformatierte Spalte und liefert trotzdem
formatierte Daten. Insbesondere kann formatiert() problemlos ein
CHAR(8) oder so etwas abliefern.
und um mal wirklich Butter bei die Fische zu geben:
Wenn du tatsächlich zu faul bist, einen Bug in einem Open-Source-
Produkt zu reporten, dann solltest du konsequenterweise von einer
Benutzung dieses Produkts Abstand nehmen. Ganz besonders solltest
du dir dümmliche Bemerkungen a'la "dann mache ich eben $WORKAROUND
bis dieser Bug gefixt ist" verkneifen. Wenn du noch nicht mal sagst,
wo dich der Schuh drückt, wie kannst du da Hilfe erwarten?
Ehrlich gesagt fehlen mir die Worte, um ein solches Verhalten
angemessen zu bezeichnen!
XL
Michael Ziegler
> Andreas Kretschmer wrote:
>> Mag sein, das dieser Rat sinnvoll erscheinen mag. Ein numerischer Wert,
>> der N Nullen vorweg führt, ist es aber nicht. Ich bin mir grad nicht
>> sicher, in welcher Klasse ich das lernte, ist lange her, aber 007 ist
>> dasselbe wie 07 ist dasselbe wie 7. [...]
>
> Ack. Daher will der OP ja keinen String, damit MySQL mit dem Ding noch
> *rechnet* wie mit einem normalen int.
Er hat nur *absolut* dabei versagt, das zu erklären. Aber wie ich
bereits schrieb, will man
SELECT ... FROM bar JOIN baz ON (formatiere(bar.foo) = baz.sabbel)
*niemals* schreiben, weil das zumindest MySQL *nicht* *performant*
ausführen kann. Und wenn darüber hinaus noch
formatiere(bar.foo) = bar.foo
gilt (die Transformation bezüglich des Vergleichs also eine Null-
operation ist), dann will man das schon gar nicht.
XL
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
On 2007-08-29, Andreas Kretschmer
> begin Florian Laws schrieb:
>> On 2007-08-28, Andreas Kretschmer
>>
>>> Selbst als MySQL-Hasser, als der ich hier bekannt bin, sehe ich nicht
>>> wirklich einen Bug. Echt.
>>>
>>> Im übrigen sehe ich *keinerlei* Grund für einen solch obskuren Datentyp
>>> wie *INT UNSIGNED ZEROFILL*. Hier scheint man bei MySQL fehlende
>>> Features wie generate_series() oder ein gescheites, kostenbasiertes
>>> EXPLAIN durch sinnfreie Konstrukte zu kaschieren. Aber das kennt man ja
>>> mittlerweile...
>>
>> Aber Du hast es ja dann doch wieder geschafft, die Kurve zum MySQL-
>> Bashing zu bekommen. Fast, aber nur fast, hättest Du mich überrascht.
>>
>> Aber was hat ZEROFILL mit generate_series() oder EXPLAIN zu tun?
>
> Nichts. Schrieb ich ja.
Ah, war sonst nicht genügend Stoff zum Bashen da?
Ich wusste nicht, dass Du es so nötig hast.
Grüße,
Florian
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
In article <3nheq4-jko.ln1@xl.homelinux.org>,
Axel Schwenke
> 1. Anscheinend können stored Functions keinen INT(n) ZEROFILL zurück
> liefern. Das ist IMNSHO ein Bug.
Was ist der Typ von "INT(n) ZEROFILL"? Bis auf die Tatsache, daß
ZEROFILL laut Manual UNSIGNED impliziert, scheint dieses Attribut nur
ein Hinweis auf die gewünschte Ausgabe-Formatierung zu sein. So
ähnlich steht's auch im Manual:
*Note*: The `ZEROFILL' attribute is stripped when a column is involved
in expressions or `UNION' queries.
Daher scheint mir das eher kein Bug zu sein - abgesehen davon, daß
ZEROFILL m.E. selbst ein Misfeature ist.
Harald Fuchs
> In article <3nheq4-jko.ln1@xl.homelinux.org>,
> Axel Schwenke
>
>> 1. Anscheinend können stored Functions keinen INT(n) ZEROFILL zurück
>> liefern. Das ist IMNSHO ein Bug.
>
> Was ist der Typ von "INT(n) ZEROFILL"?
Das ist exakt die Frage. Bei anderen Attributen wie AUTO_INCREMENT oder
PRIMARY KEY ist klar, daß die nur für Spalten eine Bedeutung haben. Für
UNSIGNED ist klar, daß das für alle Verwendungen zum Typ gehört. Für
das ZEROFILL Attribut ist die Entscheidung nicht ganz offensichtlich.
Man könnte sich also auf den Standpunkt stellen, daß ZEROFILL auch nur
im Kontext einer Tabellenspalte sinnvoll ist.
ABER:
1. Das Manual spezifiziert das nicht.
2. CREATE FUNCTION akzeptiert ZEROFILL in der RETURNS Klausel. Es ist
also davon auszugehen, daß das signifikant ist.
3. Wenn man den folgenden Testcase durch mysql -T jagt, dann *sieht*
man, daß das Funktionsergebnis als ZEROFILL getaggt ist:
~ $cat testcase.sql
DROP TABLE IF EXISTS t1;
DROP FUNCTION IF EXISTS times2;
CREATE TABLE t1 (c1 INT(8) UNSIGNED ZEROFILL);
INSERT INTO t1 VALUES (1), (2);
delimiter /
CREATE FUNCTION times2 (x INT(8) UNSIGNED ZEROFILL)
RETURNS INT(8) UNSIGNED ZEROFILL
DETERMINISTIC
BEGIN
RETURN x*2;
END /
delimiter ;
SELECT c1, times2(c1) FROM t1;
~ $mysql -T test
....
mysql> \. testcase.sql
....
Field 1: `c1`
Catalog: `def`
Database: `test`
Table: `t1`
Org_table: `t1`
Type: LONG
Collation: binary (63)
Length: 8
Max_length: 8
Decimals: 0
Flags: UNSIGNED ZEROFILL NUM
Field 2: `times2(c1)`
Catalog: `def`
Database: ``
Table: ``
Org_table: ``
Type: LONG
Collation: binary (63)
Length: 8
Max_length: 1
Decimals: 0
Flags: UNSIGNED ZEROFILL NUM
+----------+------------+
| c1 | times2(c1) |
+----------+------------+
| 00000001 | 2 |
| 00000002 | 4 |
+----------+------------+
2 rows in set (0,00 sec)
> Daher scheint mir das eher kein Bug zu sein - abgesehen davon, daß
> ZEROFILL m.E. selbst ein Misfeature ist.
Kein Widerspruch von mir hierfür. Allerdings scheint der SQL-Standard
ZEROFILL zu verlangen?
XL
Axel Schwenke schrieb:
>
> [...] will man
> SELECT ... FROM bar JOIN baz ON (formatiere(bar.foo) = baz.sabbel)
> *niemals* schreiben
Mir bleibt nichts anderes Übrig.
Die eine Spalte ist INT(11) die andere INT(8). Der Join ist auch nicht
auf die letzten 8 Stellen beschränkt (wie in dem vereinfachtem
Beispiel - sondern setzt sich aus bestimmten Stellen des barcode11
zusammen). Aber selbst wenn dem so wäre, würde der Join ja eher
zufällig passenden Reihen liefern
Ich muss also umrechnen. Die angedachte s.p. sollte - wie bereits
erwähnt - zwei Dinge auf einen Schlag liefern:
1. Den umgerechten INT für den Join und
2. die formatierte Ausgabe
, weil das zumindest MySQL *nicht* *performant*
> ausführen kann.
ACK.
>
> formatiere(bar.foo) = bar.foo
Leider nicht.
Michael Ziegler schrieb:
> Andreas Kretschmer wrote:
>> Dann laà Dir einen STRING liefern, wenn Du einen willst, und keinen INT.
>
> Er will aber weder einen String noch einen INT, sondern einen
> *INT UNSIGNED ZEROFILL* - und es gibt eigentlich keinen vernünftigen
> Grund das _nicht_ zu wollen, denn dieser Datentyp entspricht genau dem
> was gewünscht ist.
Na endlich jemand der mich versteht.
Ich hatte wohl vorher nur das Pech dem Gruppentroll gleich mehrmals
ins offene Messer zu laufen. War halt mein erstes Posting hier.
Bestimmt hat A.K. seinen Spass gehabt. Nun wandert er aber ungelesen
seiner designierten Bestimmung zu: NULL
Peter