Connecter Xata vers Excel, Google Sheets, l'IA et REST

Le champ Base de données est un itinéraire, pas un nom

Sur tous les autres connecteurs Postgres, le champ de base de données contient un identifiant, et Query Streams le convertit en minuscules lors de la transmission, conformément au comportement de Postgres avec un nom non entre guillemets. Sur Xata, ce comportement serait incorrect ; c’est pourquoi cette règle est désactivée.

• La valeur est une paire base de données:branche — mydb:main — que Xata interprète comme une route. Il ne s'agit pas d'un identifiant Postgres et il ne respecte pas les règles de repliement des identifiants.
• Une branche appelée Feature-X conserve son F majuscule et son X majuscule. En minuscules, elle cesse d'être résolue ; c'est pourquoi Xata est le seul connecteur exempté de la normalisation.
• Omettez les deux points et la connexion fonctionne toujours. — le script aboutit sur la branche par défaut. La carte le signale au lieu de laisser passer l'erreur silencieusement, car atterrir sur la branche principale au lieu d'une branche de fonctionnalité produit des chiffres apparemment corrects à partir de données erronées.
• Aucun autre élément du nom n'est vérifié. Query Streams transmet l'itinéraire tel que vous l'avez saisi et laisse Xata décider s'il est résolu.

Que fait l'agent avec un hôte Xata ?

Deux comportements sont liés au suffixe .sql.xata.sh, et vous n'avez pas la possibilité de les configurer.

• Le protocole TLS est obligatoire, mais non recommandé. Toute instance de .sql.xata.sh est établie avec le chiffrement activé, même si la case « Utiliser SSL » est cochée. Par conséquent, une chaîne de caractères dont le mode SSL a été perdu dans le presse-papiers est toujours transmise chiffrée.
• La connexion est chiffrée, mais la chaîne de certificats n'est pas vérifiée. C'est la description exacte, et c'est la même chose chez tous les fournisseurs d'hébergement reconnus par Query Streams.
• Aucun pooler n'est présent sur le chemin. Certains services Postgres sans serveur utilisent un pooler en mode transactionnel et nécessitent l'utilisation de requêtes préparées ; Xata n'en a pas besoin, l'agent se connecte donc directement et ignore cette étape.
• La connexion est enregistrée au format PostgreSQL, Xata étant conservé comme identifiant. Il n'existe pas de type de connexion appelé Xata. — ce qui signifie également qu'une simple connexion Postgres que vous avez établie précédemment avec le même hôte affichera la marque Xata.

Collez-le plutôt que de le retaper.

Quatre identifiants, dont deux sont faciles à confondre et un est suffisamment long pour qu'une erreur de frappe soit inévitable. La carte est conçue pour coller la chaîne de caractères et récupérer le reste.

• L'URI postgresql:// affichée dans la console est correcte. Le mot-clé host= de libpq est également interprété.
• Tout ce qui n'est pas une chaîne de connexion Postgres est rejeté avec un message vous indiquant où se trouve la bonne, plutôt que d'être partiellement analysé et placé dans les mauvais champs.
• Une clé API contenant des espaces en début ou en fin de chaîne est signalée. Il s'agit d'un artefact du presse-papiers, et cela provoque une erreur d'authentification classique, induisant ainsi les utilisateurs en erreur.
• L'identifiant de l'espace de travail se place dans le champ « Nom d'utilisateur » et la clé API dans le champ « Mot de passe ». La fiche les indique ainsi, plutôt que de simplement mentionner « Nom d'utilisateur » et « Mot de passe », ce qui vous laisserait le soin de deviner.

-- Postgres ordinaire, en lecture seule, sur la branche que vous avez pointée SELECT c.name, COUNT(o.id) AS orders, SUM(o.amount) AS revenue FROM public.customers AS c JOIN public.orders AS o ON o.customer_id = c.id WHERE o.placed_at >= now() - interval '30 days' GROUP BY c.name ORDER BY revenue DESC;