Bug PostGreSQL : FULL OUTER JOIN

SQLpro · 07/04/2014 12:39:52

Bonjour,

j'ai mis cela dans les publications, car il s'agit à l'évidence d'un bug majeur mais j'ai écrit un article là dessus :
Une étrange limitation de PostGreSQL

En effet, PostgreSQL sort une erreur lorsque l'on fait une jointure externe bilatérale et que le prédicat de jointure n'est pas "cherchable".

Pouvez-vous m'indiquer qui/ou contacter le staff de PG pour faire une demande de correction ?

D'avance merci

PS : je cherche une solution temporaire et rajouterais une entrée à ce blog dès que j'ai trouvé une voie de contournement...

Dernière modification par SQLpro (07/04/2014 12:53:45)

rjuju · 07/04/2014 13:55:36

Bonjour,

Si vous voulez déclarer un bug vous pouvez envoyer un message à la mailing list pgsql-bugs, ou vous reporter à la page http://www.postgresql.org/support/submitbug/ (lien disponible sur la page d'accueil du site postgresql.org).

PS: j'ai déplacé le message dans la section "Général", section plus appropriée pour votre message.

gleu · 07/04/2014 14:22:34

En l'occurence, ce n'est pas un bug mais une limitation (comme le dit le titre de votre article). À mon avis, c'est la réponse qu'ils vous donneront. Et ensuite, je pense qu'ils vous diront que si vous pouviez proposer un patch implémentant ça, ce serait d'une grande aide. Et je les joins tout à fait sur ces deux remarques

SQLpro · 07/04/2014 14:47:38

gleu a écrit :

En l'occurence, ce n'est pas un bug mais une limitation (comme le dit le titre de votre article). À mon avis, c'est la réponse qu'ils vous donneront. Et ensuite, je pense qu'ils vous diront que si vous pouviez proposer un patch implémentant ça, ce serait d'une grande aide. Et je les joins tout à fait sur ces deux remarques

Oui, enfin, ça me fait penser aux temps anciens ou MS traitait ses bugs de "fonctionnalité particulière..."

Appelons un chat un chat. C'est un bug lié à une limitation du moteur SQL.

Je poste dans la bug liste en testant sur la dernière version 9.3.4.

A +

gleu · 07/04/2014 15:03:29

Pas la peine, ça ne fonctionne pas en 9.3.4. C'est la première chose que j'ai faite. Mais bon, c'est une limitation, pas un bug. Vous ne le verrez pas implémenté pour une 9.1 par exemple. Si jamais cette limitation était supprimée, ce serait sur la prochaine version de PostgreSQL. Donc pas un bug.

SQLpro · 08/04/2014 00:05:07

Pas un bug !!!!

Là franchement je rigole....

Ne pas pouvoir fournir un résultat sur une requête triviale c'est quand même un peu gros... D'autant que Oracle et SQL Server le font sans problème !

Si c'était une limitation, ce serait précisé dans les manuels de PG...
regardez vous même : http://www.postgresql.org/docs/9.3/stat … sions.html
ça n'y est pas....

Quand à Tom Lane, il m'a bien amusé en disant, "c'est pas bien grave, personne ne s'en sert..." !
Peut être sous PG, les gens hésitent à faire des jointures de peur de casser le moteur...
Pour ma part je l'enseigne dans différentes écoles d'ingé et je l'utilise quotidiennement dans le cadre de la gestion de la qualité des données pour effectuer des rapprochements "flous"...

A +

gleu · 08/04/2014 08:15:33

Pour tout le monde, la discussion sur pgsql-bugs : http://www.postgresql.org/message-id/20 … gresql.org

Et la réponse de Tom Lane est : "This is unlikely to be simple to fix, and it's not going to be very high on anyone's priority list either, given that few people use FULL JOIN as far as I've heard."

ioguix · 08/04/2014 10:31:00

SQLpro a écrit :

Quand à Tom Lane, il m'a bien amusé en disant, "c'est pas bien grave, personne ne s'en sert..." !

Plutôt que de détourner le fond de la réponse de Tom Lane (PS: je n'ai pas l'intention d'en débattre avec vous), pourquoi ne pas avoir répondu à sa demande de plan des autres moteurs publiquement ?

Avez-vous vu sa réponse à propos du plan de SQL Serveur que vous lui avez fourni en privé ? Avez vous une réponse à lui apporter ? Ouvrez vous un bug pour être constructif ou pour d'autres raisons ?

Ps: Pourquoi dieu est-il nécessaire de faire un screenshot pour récupérer un plan sous SQL Serveur ?!

Pour historique :
http://www.postgresql.org/message-id/28 … .pgh.pa.us
http://www.postgresql.org/message-id/53 … dalibo.com

SQLpro a écrit :

Peut être sous PG, les gens hésitent à faire des jointures de peur de casser le moteur...

Ahahah
Avec tant d'humour, vos cours en école d'ingé doivent être tellement amusants !

SQLpro · 09/04/2014 11:31:59

Vos questions sont puériles, mais je vais vous répondre !

ioguix a écrit :

...pourquoi ne pas avoir répondu à sa demande de plan des autres moteurs publiquement ?

Ayant reçu un mail privé, j'ai répondu à ce mail. Est-ce mal ? Suis-je stupide ?

Avez-vous vu sa réponse à propos du plan de SQL Serveur que vous lui avez fourni en privé ?

Je n'ais pas eu de réponse en retour de mon mail envoyé en privé !

Avez vous une réponse à lui apporter ?

N'ayant pas eu son retour je ne voit pas quelle réponse à apporter à aucune question en retour...

Ouvrez vous un bug pour être constructif ou pour d'autres raisons ?

Et vous, avec ce post, pensez-vous réellement constructifs ? Moi je pense que vous maîtrisez l'art d'enculer les mouches...
D'autre part, il se trouve que je travaille et hier j'étais chez Alstom, un de mes clients, oub comme par hasard nous allons passer d'une base PostGreSQL qui donne des performances lamentables à une base SQL Server....
je suis revenu à 21h chez moi et j'avoue que je n'avais plus le temps de me consacrer àn PG...
Peut être êtes vous un fonctionnaire effectuant 32 h par semaine avec 8 semaines de congés payé.. pas moi, j'ai une boite à faire fonctionner et des cours à donner à des ingénieurs...

Ps: Pourquoi dieu est-il nécessaire de faire un screenshot pour récupérer un plan sous SQL Serveur ?!

Vous simplifiez de manière parfaitement stupide l'envoi que j'ai fait; J'espère que c'est par ignorance... Car si c'était pas volonté, cela prouverait votre niveau de mauvaise foi...
Donc pour faire simple :
les plans de requête détaillés sont fournit par SQL Server sous forme XML dont voici un exemple :

<?xml version="1.0" encoding="utf-16"?>
<ShowPlanXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Version="1.1" Build="10.50.4000.0" xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan">
  <BatchSequence>
    <Batch>
      <Statements>
        <StmtSimple StatementCompId="1" StatementEstRows="4" StatementId="1" StatementOptmLevel="FULL" StatementOptmEarlyAbortReason="GoodEnoughPlanFound" StatementSubTreeCost="0.0133358" StatementText="SELECT *&#xD;&#xA;FROM   T_CLIENT_CLI AS C&#xD;&#xA;       FULL OUTER JOIN T_PROSPECT_PSP AS P&#xD;&#xA;            ON C.CLI_SIREN = P.PSP_SIREN&#xD;&#xA;            OR C.CLI_ENSEIGNE = P.PSP_ENSEIGNE" StatementType="SELECT" QueryHash="0x9365EE9F42E3675B" QueryPlanHash="0xBC472FE59224297A">
          <StatementSetOptions ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" NUMERIC_ROUNDABORT="false" QUOTED_IDENTIFIER="true" />
          <QueryPlan CachedPlanSize="24" CompileTime="5" CompileCPU="5" CompileMemory="280">
            <RelOp AvgRowSize="57" EstimateCPU="0.00581814" EstimateIO="0.000939" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="4" LogicalOp="Full Outer Join" NodeId="0" Parallel="false" PhysicalOp="Merge Join" EstimatedTotalSubtreeCost="0.0133358">
              <OutputList>
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
                <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
              </OutputList>
              <Merge ManyToMany="true">
                <InnerSideJoinColumns />
                <OuterSideJoinColumns />
                <Residual>
                  <ScalarOperator ScalarString="[tempdb].[dbo].[T_CLIENT_CLI].[CLI_SIREN] as [C].[CLI_SIREN]=[tempdb].[dbo].[T_PROSPECT_PSP].[PSP_SIREN] as [P].[PSP_SIREN] OR [tempdb].[dbo].[T_CLIENT_CLI].[CLI_ENSEIGNE] as [C].[CLI_ENSEIGNE]=[tempdb].[dbo].[T_PROSPECT_PSP].[PSP_ENSEIGNE] as [P].[PSP_ENSEIGNE]">
                    <Logical Operation="OR">
                      <ScalarOperator>
                        <Compare CompareOp="EQ">
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
                            </Identifier>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
                            </Identifier>
                          </ScalarOperator>
                        </Compare>
                      </ScalarOperator>
                      <ScalarOperator>
                        <Compare CompareOp="EQ">
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
                            </Identifier>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
                            </Identifier>
                          </ScalarOperator>
                        </Compare>
                      </ScalarOperator>
                    </Logical>
                  </ScalarOperator>
                </Residual>
                <RelOp AvgRowSize="33" EstimateCPU="0.0001603" EstimateIO="0.003125" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="3" LogicalOp="Clustered Index Scan" NodeId="1" Parallel="false" PhysicalOp="Clustered Index Scan" EstimatedTotalSubtreeCost="0.0032853" TableCardinality="3">
                  <OutputList>
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
                  </OutputList>
                  <IndexScan Ordered="false" ForcedIndex="false" ForceScan="false" NoExpandHint="false">
                    <DefinedValues>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
                      </DefinedValue>
                    </DefinedValues>
                    <Object Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Index="[PK__T_CLIENT__D0BA12001DE57479]" Alias="[C]" IndexKind="Clustered" />
                  </IndexScan>
                </RelOp>
                <RelOp AvgRowSize="33" EstimateCPU="0.0001614" EstimateIO="0.003125" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="4" LogicalOp="Clustered Index Scan" NodeId="2" Parallel="false" PhysicalOp="Clustered Index Scan" EstimatedTotalSubtreeCost="0.0032864" TableCardinality="4">
                  <OutputList>
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
                    <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
                  </OutputList>
                  <IndexScan Ordered="false" ForcedIndex="false" ForceScan="false" NoExpandHint="false">
                    <DefinedValues>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
                      </DefinedValue>
                    </DefinedValues>
                    <Object Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Index="[PK__T_PROSPE__3FA9CAA424927208]" Alias="[P]" IndexKind="Clustered" />
                  </IndexScan>
                </RelOp>
              </Merge>
            </RelOp>
          </QueryPlan>
        </StmtSimple>
      </Statements>
    </Batch>
  </BatchSequence>
</ShowPlanXML>

Trouvez vous cela plus facile que la représentation graphique ?

Bien entendu, c'est ce XML qui est interprété graphiquement. mais n'étant pas sur que Tom lane dispose de l'outil de lecture des plans, j'ai envoyé les deux par sécurité...
Ais-je bien fait ou suis-je à vos yeux un crétin ?

Ahahah
Avec tant d'humour, vos cours en école d'ingé doivent être tellement amusants !

Effectivement, vous en avez tellement !!!

Mais ce qui est pire dans votre comportement, c'est que vous ne me donnez pas du tout envie de continuer à traiter ce sujet et donc votre mail aura l'effet inverse de celui escompté : j'abandonne la partie ! Ayant dû consacré 1h pour répondre à vos attaques infantiles, c'est 1h de perdu pour répondre à Tom lane...

A +

arthurr · 09/04/2014 12:21:23

Que d'insultes ...

ioguix · 09/04/2014 13:59:41

SQLpro a écrit :

ioguix a écrit :
...pourquoi ne pas avoir répondu à sa demande de plan des autres moteurs publiquement ?
Ayant reçu un mail privé, j'ai répondu à ce mail. Est-ce mal ? Suis-je stupide ?

Oh, soit. Vous n'étiez pas obligé de savoir que pgsql-bugs est une liste de diffusion...
Ceci dit, notez que Tom Lane vous a répondu avec cette liste en copie et non en privé:

http://www.postgresql.org/message-id/19 … .pgh.pa.us

SQLpro a écrit :

Avez-vous vu sa réponse à propos du plan de SQL Serveur que vous lui avez fourni en privé ?
Je n'ais pas eu de réponse en retour de mon mail envoyé en privé !

Si si, mais sur la liste en directe. Donc pour information:

http://www.postgresql.org/message-id/28 … .pgh.pa.us

SQLpro a écrit :

Ouvrez vous un bug pour être constructif ou pour d'autres raisons ?
Et vous, avec ce post, pensez-vous réellement constructifs ? Moi je pense que vous maîtrisez l'art d'enculer les mouches...
D'autre part, il se trouve que je travaille et hier j'étais chez Alstom, un de mes clients, oub comme par hasard nous allons passer d'une base PostGreSQL qui donne des performances lamentables à une base SQL Server....
je suis revenu à 21h chez moi et j'avoue que je n'avais plus le temps de me consacrer àn PG...
Peut être êtes vous un fonctionnaire effectuant 32 h par semaine avec 8 semaines de congés payé.. pas moi, j'ai une boite à faire fonctionner et des cours à donner à des ingénieurs...

Disons que face à votre non contribution, je me posais bien des questions. Maintenant, je comprends que vous ne suivez simplement pas la liste de discussion, et donc la discussion à propos de votre bug.

Quant à votre expérience, je ne vois pas tellement quoi en faire sans le contexte. "Comme par hasard", il y a 1000 façon de détruire ce retour d'expérience. Je ne m'y emploierais pas car vu le changement de ton que vous avez initié, je ne souhaite pas argumenter avec vous.

À propos de mon temps de travail...pareille, trop simple à détruire, trop bas, je vous laisse dans votre imaginaire.

SQLpro a écrit :

Ps: Pourquoi dieu est-il nécessaire de faire un screenshot pour récupérer un plan sous SQL Serveur ?!

Vous simplifiez de manière parfaitement stupide l'envoi que j'ai fait; J'espère que c'est par ignorance... Car si c'était pas volonté, cela prouverait votre niveau de mauvaise foi...

Je vous rassure, c'est par pure ignorance de SQL Server, sinon, je n'aurais pas posé la question. Et oui, je suis curieux, que voulez vous.

SQLpro a écrit :

Donc pour faire simple :
les plans de requête détaillés sont fournit par SQL Server sous forme XML dont voici un exemple :
...
Trouvez vous cela plus facile que la représentation graphique ?
Bien entendu, c'est ce XML qui est interprété graphiquement. mais n'étant pas sur que Tom lane dispose de l'outil de lecture des plans, j'ai envoyé les deux par sécurité...
Ais-je bien fait ou suis-je à vos yeux un crétin ?

Vous auriez pu proposer les deux représentations par soucis du détail. Ceci dit, ça ne fait pas de vous un crétin, peut-être en faite vous un peu trop non ?

SQLpro a écrit :

Ahahah
Avec tant d'humour, vos cours en école d'ingé doivent être tellement amusants !

Effectivement, vous en avez tellement !!!

Mais ce qui est pire dans votre comportement, c'est que vous ne me donnez pas du tout envie de continuer à traiter ce sujet et donc votre mail aura l'effet inverse de celui escompté : j'abandonne la partie ! Ayant dû consacré 1h pour répondre à vos attaques infantiles, c'est 1h de perdu pour répondre à Tom lane...

Mh, votre choix. En attendant, le message est passé sur pgsql-bugs, donc si vous n'avez plus rien à y apporter hein...

SQLpro · 09/04/2014 14:21:58

ioguix a écrit :

Oh, soit. Vous n'étiez pas obligé de savoir que pgsql-bugs est une liste de diffusion...
Ceci dit, notez que Tom Lane vous a répondu avec cette liste en copie et non en privé:

je tenais aussi à signaler que lorsque j'ai posté le bug dans la liste celui-ci n'a pas été publié... Peut être une modération à priori.. Ok, mais par exemple dans Microsoft Connect, il n'y a pas de modération (PostGreSQL aurait-il il des choses à cacher ???). Certes, il faut se faire reconnaître préalablement chhez MS, mais cela ne prends que quelques secondes...
Raisons pour laquelle j'ai ignoré la liste :
1) par le fait que le mail m'ait été adressé personnellement
2) parce que celui ci n'étais pas diffusé sur la liste au moment ou je suis aller y regardé.
3) mon client de messagerie, ne propose par par défaut l'option inclus donc le mail dans la liste de diffusion... (c'est d'ailleurs un outil Free : Mozilla !!!!! va falloir que je change pour OutLook...)

Avez-vous vu sa réponse à propos du plan de SQL Serveur que vous lui avez fourni en privé ?

Ce midi, oui, et je fais le même constat que lui....
Comme je n'ais pas d'autres commentaires et que je gâche du temps à répondre à vos inepties...

Disons que face à votre non contribution, je me posais bien des questions. Maintenant, je comprends que vous ne suivez simplement pas la liste de discussion, et donc la discussion à propos de votre bug.

je n'ai tout simplement pas eu le temps... Je ne consacre pas tout mon temps à PG... Je travaille aussi !

Quand à ma "non contribution" je considère qu'il s'agit de votre part d'une insukte. En effet une contribution pour éradiquer un bug qu'il ne vous plait pas de voir exposer est une insulte intellectuelles, à peu près équivalentes à celles des totalitarismes, qui ne supportent pas de voir exposer des défaillances dans leurs systèmes et préfèrent couper la tête à ceux qui les exposent !

Vous auriez pu proposer les deux représentations par soucis du détail. Ceci dit, ça ne fait pas de vous un crétin, peut-être en faite vous un peu trop non ?

MAIS C 'EST EXACTEMENT CE QUE J'AI FAIT !!!! J'AI ENVOYÉ LES DEUX À TOM LANE (ET MÊME 3 VERSION PAR SÉCURITÉ : TEXTE, XML et GRAPHIQUE !). DE PLUS JE VOUS L'AI DIT DANS MON PRÉCÉDENT POST MAIS VISIBLEMENT VOUS AVEZ UN PROBLÈME DE VUE !!!!

A +

jpargudo · 09/04/2014 14:27:53

Monsieur Brouard,

Le commentaire ci-dessous provoque chez moi stupeur et questions.

SQLpro a écrit :

[...] il se trouve que je travaille et hier j'étais chez Alstom, un de mes clients, oub comme par hasard nous allons passer d'une base PostGreSQL qui donne des performances lamentables à une base SQL Server.... [...]

Stupeur, tout d'abord, car je trouve très moyen qu'en grand professionnel de l'informatique auto-proclamé vous vous permettiez de raconter ce que vous faites chez vos clients. De notre côté, nous signons des accords de confidentialité, comme par exemple, avec l'industrie. Peu importe, ce point ne regarde que vous.

Questions, ensuite: pouvez-vous nous en dire un peu plus sur ce cas d'utilisation? C'est à dire expliquer concrètement ce que vous avez mis en œuvre pour résoudre les problèmes liés à PostreSQL chez ce client? À moins que ce dernier n'ait choisi de migrer à SQL Server pour d'autres raisons que celle que vous invoquez? Quoi qu'il en soit, merci de vous en tenir aux faits.

Ah, et, si possible, des faits réels, car vous avez une fâcheuse tendance à l'affabulation, comme vous l'avez démontré au sujet du site "Le Bon Coin" (voir vos propos péremptoires ici : http://forums.postgresql.fr/viewtopic.p … 126#p19126, démentis par l'un des responsables techniques du même site ici : http://forums.postgresql.fr/viewtopic.p … 137#p19137 (et suivants)).

Bien à vous,

ioguix · 09/04/2014 14:36:19

SQLpro a écrit :

Disons que face à votre non contribution, je me posais bien des questions. Maintenant, je comprends que vous ne suivez simplement pas la liste de discussion, et donc la discussion à propos de votre bug.
je n'ai tout simplement pas eu le temps... Je ne consacre pas tout mon temps à PG... Je travaille aussi !
Quand à ma "non contribution" je considère qu'il s'agit de votre part d'une insukte. En effet une contribution pour éradiquer un bug qu'il ne vous plait pas de voir exposer est une insulte intellectuelles, à peu près équivalentes à celles des totalitarismes, qui ne supportent pas de voir exposer des défaillances dans leurs systèmes et préfèrent couper la tête à ceux qui les exposent !

Hahaha, génial ! Veuillez m'excuser, cher Monsieur, pour ma formulation qui pouvait prêter, je l'admet, à confusion. Ce que je pensais en écrivant cette phrase était :

ioguix a écrit :

Disons que face à votre non contribution à la suite de cette discussion, ...

Bon, vous aurez réussi à me faire sourire malgré tout :-)

Maintenant, j'arrête là, tout ça ne mène nulle part. Vous ne me semblez pas être dans vos meilleurs dispositions de toute façon et j'ai un métier aussi, figurez vous ;-)

guk92 · 22/04/2014 21:10:25

Bonsoir,

Ce n'est pas comme s'il n'y avait pas de bug sous SQL Server.

Voici un topic qui détaille un problème majeur que j'ai rencontré avec SQL Server 2005 :
http://www.developpez.net/forums/d11183 … -bug-like/

Il ne s'agit même pas d'un FULL JOIN, mais du pauvre opérateur LIKE...

Je préfère de loin avoir un SGBDR gratuit qui m'avertit ne pas gérer une fonctionnalité, qu'un SGBDR payant qui me sort des conneries.

En ce qui concerne la bug list de SQL Server, on peut lire sur internet :

Microsoft doesn't really keep a public list of open bugs. The ones that are the most important (e.g. anything involving security) are kept private for obvious reasons - they actually aren't published until they are fixed (and even then they often remain private).

Source : http://dba.stackexchange.com/questions/ … er-sp4-cu4

SQLpro · 24/04/2014 18:30:19

guk92 a écrit :

Bonsoir,

Ce n'est pas comme s'il n'y avait pas de bug sous SQL Server.
Voici un topic qui détaille un problème majeur que j'ai rencontré avec SQL Server 2005 :
http://www.developpez.net/forums/d11183 … -bug-like/
Il ne s'agit même pas d'un FULL JOIN, mais du pauvre opérateur LIKE...

Je préfère de loin avoir un SGBDR gratuit qui m'avertit ne pas gérer une fonctionnalité, qu'un SGBDR payant qui me sort des conneries.

En ce qui concerne la bug list de SQL Server, on peut lire sur internet :
Microsoft doesn't really keep a public list of open bugs. The ones that are the most important (e.g. anything involving security) are kept private for obvious reasons - they actually aren't published until they are fixed (and even then they often remain private).
Source : http://dba.stackexchange.com/questions/ … er-sp4-cu4

Le nombre de bug de SQL Server est bien moindre, tous moteurs confondus (SQL Server contient un ETL de nom SSIS, un moteur de stockage décisionnel en plus du relationnel, des outils de data mining et de formation de datamart SSAS, des outils de reporting SSRS et de très nombreux outils de maintenance, audit et admin......etc.) que ceux de PG... SQL Server compte à peu près 30 fois plus de code que PG, pour juste 20 fois moins de bug... Lisez les métriques du NIST par exemple sur les vulnérabilités... N'avez vous pas eu récemment une vulnérabilité importante sur PG récemment ? Depuis 2010, 26 vulnérabilités ont été recensées dans PG (http://www.postgresql.org/support/security/) contre 5 dans SQL Server (source NIST)... Comparez au volume de code, cela fait donc 150 fois plus de problème relativement dans PG que dans SQL Server... une toute petite paille !

A +

guk92 · 25/04/2014 11:45:03

Bonjour,

A comparer 2 SGBDR gratuits, je dirais qu'il faudrait comparer PostgreSQL et SQL Server Express.
SQL Server Express ne dispose ni d'ETL (SSIS), ni d'outil de création de cube (SSAS), ni d'outil pour mettre en forme les rapports (SSRS), ni de l'outil de tâche planifié (SQL Server Agent) par défaut...
Ce sont certes des outils utiles, mais pas indispensable non plus (j'achète une voiture pour rouler, pas pour ses sièges en cuir), car il existe d'autres alternatives, parfois moins couteuse et aussi bien (pour la partie integration je pense à Talend, et reporting à Qlikview), ou bien même gratuit (du développement).
Pour la partie cube, je trouve que le cas s'applique peut-être bien pour les cas extrême où on a vraiment beaucoup de donnée (la traçabilité de tous les produits dans une usine de production par exemple), mais sinon ça reste quand même très marketing comme solution.

SQL Server compte 30 fois plus de code que PG ? Je ne savais pas que SQL Server était open source...
Le rapport nombre de ligne de code / vulnérabilité est certainement meilleure avec SQL Server (et encore heureux pour le prix que ça coute, faut un minimum). Le nombre de ligne de code ne veut pas tout dire, et si ça se trouve les chiffres inclus SSIS, SSAS, SSRS dedans (cf: on ne le sait pas, cqfd: n'est pas open source).
Je trouve le lien des bugs PostgreSQL cool, par contre dommage je n'arrive pas à trouver la même interface publique pour SQL Server (ne pas ternir l'image de marque est compréhensible pour une très grande entreprise). Ce qu'il faudrait voir c'est le temps moyen prit pour résoudre un bug.

Voici un article developpez intéressant sur la qualité du code open source / propriétaire :
http://www.developpez.net/forums/d14327 … ost7780066

Et rapport (voir page 8 pour la densité de défaut) : http://www.coverity.com/library/pdf/cov … report.pdf
Qu'en est-t-il de SQL Server ?

Mais pourquoi parle-t-on toujours de bug ? Le problème de base est lié à une limitation

Dernière modification par guk92 (25/04/2014 11:45:50)

SQLpro · 25/04/2014 16:14:18

De mémoire, la vitesse de correction des bugs de MS est de moins de 3 mois. Le faible nombre de bugs, comme la rapidité de correction est le fait du Microsoft's Secure Development Lifecycle, une méthodologie destinée à aider les développeurs de MS à construire des systèmes plus résilients et naturellement plus fiables. À l'époque de 2005, l'équipe de test était constitué d'une quinzaine de personne, mais surtout de plus de 160 machines de tests et le système tournait toutes les nuits pour rendre le résultat le matin aux équipes...

Le pire bugs en durée de correction avait été des télescopages de clef auto-incrémentées lorsque le nombre de requête d'insertion simultanées dans la même table dépassait le nombre de cœurs pour des machines de plus de 64 cœurs et lorsque la requête est parallélisée.... pas le genre de bugs que l'on risque de trouver sur PG qui ne sait pas faire des requête parallélisées !

Je trouve le site de publication/correction des bugs de MS (connect), nettement mieux fait et plus pratique que ce que propose PG avec sa liste... ! La preuve, c'est que je m'y suis trompé et on me l'a reproché !!!

L'étude de Coverity m'avait beaucoup fait rire, car c'est un spécialiste de l'open source (slogan : "Coverity Scan: free code analysis service for open source developers"), n'ayant visiblement aucune compétence, dans le code MS ou autre (IBM par exemple)... Et qui trouve bon ce qu'il sait auditer et pas le reste !!! vraiment de quoi se marrer !!!!

guk92 a écrit :

Mais pourquoi parle-t-on toujours de bug ? Le problème de base est lié à une limitation

NON ! Quelque chose qui renvoie une erreur alors qu'il n'y a pas lieu c'est un bug.

A +

Dernière modification par SQLpro (25/04/2014 16:20:02)

#1 07/04/2014 12:39:52

Bug PostGreSQL : FULL OUTER JOIN

#2 07/04/2014 13:55:36

Re : Bug PostGreSQL : FULL OUTER JOIN

#3 07/04/2014 14:22:34

Re : Bug PostGreSQL : FULL OUTER JOIN

#4 07/04/2014 14:47:38

Re : Bug PostGreSQL : FULL OUTER JOIN

#5 07/04/2014 15:03:29

Re : Bug PostGreSQL : FULL OUTER JOIN

#6 08/04/2014 00:05:07

Re : Bug PostGreSQL : FULL OUTER JOIN

#7 08/04/2014 08:15:33

Re : Bug PostGreSQL : FULL OUTER JOIN

#8 08/04/2014 10:31:00

Re : Bug PostGreSQL : FULL OUTER JOIN

#9 09/04/2014 11:31:59

Re : Bug PostGreSQL : FULL OUTER JOIN

#10 09/04/2014 12:21:23

Re : Bug PostGreSQL : FULL OUTER JOIN

#11 09/04/2014 13:59:41

Re : Bug PostGreSQL : FULL OUTER JOIN

#12 09/04/2014 14:21:58

Re : Bug PostGreSQL : FULL OUTER JOIN

#13 09/04/2014 14:27:53

Re : Bug PostGreSQL : FULL OUTER JOIN

#14 09/04/2014 14:36:19

Re : Bug PostGreSQL : FULL OUTER JOIN

#15 22/04/2014 21:10:25

Re : Bug PostGreSQL : FULL OUTER JOIN

#16 24/04/2014 18:30:19

Re : Bug PostGreSQL : FULL OUTER JOIN

#17 25/04/2014 11:45:03

Re : Bug PostGreSQL : FULL OUTER JOIN

#18 25/04/2014 16:14:18

Re : Bug PostGreSQL : FULL OUTER JOIN

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux