Je m'empresse de partager la bonne nouvelle: la vie des auteurs d'articles sur PostgreSQL et de leurs lecteurs s'est un peu améliorée.
Comme tous les habispisters le savent, pour concevoir le code source, une
<source> spéciale est utilisée, qui met en évidence la syntaxe. Ce n'est pas un secret que le rétro-éclairage n'est pas toujours parfait, puis les auteurs (qui se soucient de l'apparence de leurs articles) sont contraints de se livrer à des performances amateurs - pour colorer leur code avec
<font color=...> .
Tout était particulièrement triste avec PostgreSQL, car la mise en évidence couvrait le SQL plus ou moins standard et ne comprenait catégoriquement pas les spécificités de notre SGBD. Au fil du temps, Alexey
boomburum a soigneusement corrigé mes
polices à la source (et je suis revenu), jusqu'à ce qu'il devienne évident que le rétro-éclairage devait être corrigé. Enfin, Daler
daleraliyorov a suggéré une solution: ajouter le support PostgreSQL à la bibliothèque
highlightjs utilisée par Habr. Et maintenant - terminé, bienvenue.
pgsql: SQL, PL / pgSQL et tout-tout
Ainsi, le secret de la mise en évidence correcte est dans le nouveau langage
pgsql . Il peut être sélectionné dans le menu (bouton "code source") ou spécifié manuellement. En html vous devez écrire
<source lang="pgsql">
</source>
et en démarque comme ceci:
```pgsql
```
En principe, highlightjs peut déterminer le langage lui-même, mais normalement il ne fonctionne que pour les gros fragments de code; en petits morceaux, la détection automatique manque souvent. De plus, la détection automatique prend du temps, donc si vous spécifiez la langue explicitement, le code brillera plus rapidement.
Par exemple, pour obtenir
CREATE TABLE aircrafts_data ( aircraft_code character(3) NOT NULL, model jsonb NOT NULL, range integer NOT NULL, CONSTRAINT aircrafts_range_check CHECK ((range > 0)) );
nous écrivons
<source lang="pgsql">
CREATE TABLE aircrafts_data (
aircraft_code character(3) NOT NULL,
model jsonb NOT NULL,
range integer NOT NULL,
CONSTRAINT aircrafts_range_check CHECK ((range > 0))
);
</source>
Le même langage pgsql colore également le code PL / pgSQL. Par exemple, pour obtenir
CREATE FUNCTION get_available_flightid(date) RETURNS SETOF integer AS $$ BEGIN RETURN QUERY SELECT flightid FROM flight WHERE flightdate >= $1 AND flightdate < ($1 + 1); IF NOT FOUND THEN RAISE EXCEPTION ' : %.', $1; END IF; RETURN; END $$ LANGUAGE plpgsql;
écrire
<source lang="pgsql">
CREATE FUNCTION get_available_flightid(date) RETURNS SETOF integer AS $$
...
$$ LANGUAGE plpgsql;
</source>
Une légère subtilité est que les chaînes de caractères entourées de dollars sont
toujours mises en surbrillance sous forme de code, et les chaînes dans les apostrophes ne sont jamais surlignées. J'ai envisagé différentes options, mais celle-ci semblait la plus adéquate.
La capacité de highlightjs à détecter automatiquement la langue d'un fragment permet de mettre en évidence des fonctions dans d'autres langues. Par exemple, tout fonctionnera pour PL / Perl:
CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS $$ my ($x, $y) = @_; if (not defined $x) { return undef if not defined $y; return $y; } return $x if not defined $y; return $x if $x > $y; return $y; $$ LANGUAGE plperl;
Vous n'avez besoin de rien de spécial, écrivez simplement
<source lang="pgsql">
CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS $$
...
$$ LANGUAGE plperl;
</source>
Bien sûr, la langue choisie ne dépend que de ce qui est écrit à l'intérieur des dollars, et en aucune façon déterminée par ce qui est écrit après LANGUAGE.
En général, le rétroéclairage correspond à la 11e version de PostgreSQL récemment publiée.
Il y avait beaucoup de doute sur les fonctionnalités de mise en évidence. Malheureusement, pour distinguer un nom de fonction d'un, par exemple, un nom de table, une analyse complète est nécessaire, mais cela n'est pas résolu dans la coloration syntaxique. Vous pouvez faire une longue liste de fonctions standard et les colorer, mais qu'en est-il des fonctions de nombreuses extensions? En conséquence, j'ai décidé de ne pas colorier du tout - tout de même, tout repose sur des mots clés, et la panachure est réduite.
texte en clair: texte, texte brut
Parfois, dans l'article, il est nécessaire de formaliser les résultats de la requête. Bien sûr, il n'y a pas de mots clés, rien ne doit être mis en évidence, mais je veux que le texte ressemble à «console», tout comme le code. Pour cela, vous pouvez maintenant utiliser le langage spécial en
texte brut . Par exemple, pour obtenir
WITH xmldata(data) AS (VALUES ($$ <example xmlns="http://example.com/myns" xmlns:B="http://example.com/b"> <item foo="1" B:bar="2"/> <item foo="3" B:bar="4"/> <item foo="4" B:bar="5"/> </example>$$::xml) ) SELECT xmltable.* FROM XMLTABLE(XMLNAMESPACES('http://example.com/myns' AS x, 'http://example.com/b' AS "B"), '/x:example/x:item' PASSING (SELECT data FROM xmldata) COLUMNS foo int PATH '@foo', bar int PATH '@B:bar');
foo | bar -----+----- 1 | 2 3 | 4 4 | 5 (3 rows)
écrire
<source lang="pgsql">
WITH xmldata(data) AS (VALUES ($$
...
</source>
<source lang="plaintext">
foo | bar
-----+-----
1 | 2
3 | 4
4 | 5
(3 rows)
</source>
Le texte en clair doit toujours être spécifié explicitement; il n'est pas détecté automatiquement.
J'espère que vous aimerez l'innovation et que vous serez utile. Si vous trouvez une erreur dans la façon dont le code est mis en surbrillance (et que les erreurs sont inévitables, la syntaxe contextuelle est trop pour SQL), créez une tâche sur le
github du projet et, mieux encore, proposez une solution.
PS N'oubliez pas la conférence PGConf , qui se tiendra du 4 au 6 février à Moscou. Les demandes de rapports sont acceptées jusqu'au 5 décembre!