연결하다 자타 엑셀, 구글 시트, AI 및 REST로

데이터베이스 필드는 이름이 아니라 경로입니다.

다른 모든 Postgres 커넥터에서 Database 필드는 식별자를 저장하며, Query Streams는 Postgres가 따옴표 없이 이름을 처리하는 방식대로 해당 식별자를 소문자로 변환합니다. 하지만 Xata에서는 그렇게 하는 것이 잘못된 것이므로, 이 규칙이 비활성화된 유일한 부분입니다.

• 값은 데이터베이스:브랜치 쌍입니다. — mydb:main — Xata는 이를 경로로 해석합니다. 이는 Postgres 식별자가 아니며 식별자 접기 규칙을 따르지 않습니다.
• Feature-X라는 이름의 분기는 F와 X를 모두 대문자로 유지합니다. 소문자로 feature-x로 변환하면 더 이상 인식되지 않으므로 Xata는 정규화에서 제외되는 유일한 커넥터입니다.
• 콜론을 빼도 연결은 여전히 작동합니다. — 기본 브랜치로 이동합니다. 이 카드는 오류를 조용히 넘기지 않고 알려주는 이유는, 기능 브랜치를 의도했는데 메인 브랜치로 이동하면 잘못된 데이터로 인해 겉보기에는 올바른 결과가 나오기 때문입니다.
• 이름에 대한 다른 정보는 전혀 확인되지 않습니다. Query Streams는 사용자가 입력한 경로를 그대로 전달하고 Xata가 해당 경로가 해석될지 여부를 결정하도록 합니다.

에이전트가 Xata 호스트에서 수행하는 작업

.sql.xata.sh 접미사와 관련된 두 가지 동작이 있으며, 둘 다 사용자가 구성할 수 있는 사항이 아닙니다.

• TLS는 필수 사항이며, 요청 사항이 아닙니다. 'SSL 사용' 옵션 활성화 여부와 관계없이 모든 .sql.xata.sh 호스트는 암호화되어 연결되므로, 클립보드에서 sslmode 정보가 손실된 문자열도 암호화된 상태로 전송됩니다.
• 연결은 암호화되었지만 인증서 체인은 검증되지 않았습니다. 이것이 솔직한 설명이며, Query Streams가 인식하는 모든 호스팅 제공업체에서 동일합니다.
• 경로에 풀러가 없습니다. 일부 서버리스 PostgreSQL 서비스는 트랜잭션 모드 풀러를 앞에 두고 이를 처리하기 위해 준비된 문을 고정해야 하지만, Xata는 그렇지 않으므로 에이전트가 직접 연결하여 이 모든 과정을 건너뜁니다.
• 연결 정보는 PostgreSQL 형식으로 저장되며, Xata는 배지로 유지됩니다. Xata라는 이름의 연결 유형은 존재하지 않습니다. 즉, 이전에 동일한 호스트에 연결했던 일반 Postgres 연결도 Xata 브랜드를 즉시 인식하게 된다는 의미입니다.

다시 입력하는 대신 붙여넣으세요

자격 증명은 총 네 개인데, 그중 두 개는 혼동하기 쉽고 하나는 너무 길어서 오타가 발생하기 쉽습니다. 이 카드는 문자열을 붙여넣고 나머지를 잡아내는 방식으로 설계되었습니다.

• 콘솔에서 입력된 postgresql:// URI는 예상대로입니다. libpq의 host= 키워드 형식도 정상적으로 파싱됩니다.
• Postgres 연결 문자열이 아닌 모든 것은 잘못된 필드로 부분적으로 파싱되는 대신, 올바른 연결 문자열의 위치를 알려주는 메시지와 함께 거부됩니다.
• API 키의 앞뒤에 공백이 있는 경우 문제가 발생합니다. 이는 클립보드에서 발생하는 오류이며, 일반적인 인증 오류로 인식되어 사용자가 잘못된 문제 해결 방법을 찾게 만듭니다.
• 워크스페이스 ID는 사용자 이름 필드에, API 키는 비밀번호 필드에 입력합니다. 카드에는 '사용자 이름'과 '비밀번호'라고만 표시되어 사용자가 추측하게 하는 대신, 워크스페이스 ID와 API 키를 명확하게 표시해 줍니다.

-- 일반 Postgres, 읽기 전용, 지정한 분기에 대해 다음 쿼리를 실행합니다. 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;