[Bug]: Tabularis cannot connect to PostgreSQL via kubectl port-forward while pgAdmin works

[getsueineko]

Describe the bug

Description

Tabularis fails to connect to a PostgreSQL instance exposed locally via kubectl port-forward.
The client returns the following error:

Error: error communicating with database: failed to lookup address information: nodename nor servname provided, or not known

However, the same database connection works correctly when using pgAdmin and psql, which suggests the database itself and the port-forward are functioning correctly.

This indicates a potential issue in how Tabularis resolves or parses the connection parameters.

To Reproduce

Steps to reproduce
1. Expose PostgreSQL service locally using port-forward:
kubectl port-forward svc/postgres 5432:5432
2. Connect using pgAdmin:
Host: localhost Port: 5432 Database: postgres User: postgres
Connection succeeds.
3. Attempt the same connection in Tabularis using identical parameters.
4. Tabularis returns:
Error: error communicating with database: failed to lookup address information: nodename nor servname provided, or not known

OS Version

macOS 26.3.1

Tabularis Version

v0.9.6

Relevant Log Output

[debba]

Thanks for feedback.
Are you able to debug from code?
I am afk now but I can do a check later

[debba]

@getsueineko i suspected is something related to localhost resolution.
But i am afk.
I sent the request to Claude Code If you want to do a check I referenced the commit in this issue if you want check.

I will check when I'll back

[getsueineko]

I'm not rustman =)

I tried to debug the connection using tcpdump while connecting Tabularis to a PostgreSQL instance exposed via kubectl port-forward.

Command used:

sudo tcpdump -i lo0 -X port 53729

Connection sequence observed:
1. TCP handshake completes successfully.
2. Client sends PostgreSQL SSLRequest:
0000 0008 04d2 162f
3. Server responds with S (SSL supported).
4. Client starts TLS handshake (ClientHello).
The packet begins with:
16 03 03
5. Inside ClientHello the SNI value appears to be 127.0.0.1.
6. Server immediately responds with a TLS alert:
15 03 03 00 02 02 46
which corresponds to:
TLS fatal alert: certificate_unknown
7. After that the server closes the TCP connection (FIN).

So the connection flow looks like:

TCP connect
→ SSLRequest
→ server returns S
→ TLS ClientHello (SNI=127.0.0.1)
→ TLS alert certificate_unknown
→ connection closed.

This suggests the failure happens during TLS negotiation rather than PostgreSQL authentication.

The instance is accessed through kubectl port-forward, so the client connects to 127.0.0.1, while the PostgreSQL server certificate is issued for the Kubernetes service hostname like postgres.default.svc.cluster.local

[debba]

I will definitely check it when I will be on pc

[debba]

@getsueineko Can you check if #77 has been solved the issue?
It's on main branch now.

[getsueineko]

Version 0.9.7 - the same error occurs when selecting any of the four SSL modes, but now the menu for selecting databases works, meaning there is a connection, but at the same time, there isn't one.
Maybe the problem is in the http/https scheme?? I use http