Обсуждение: Decicision needed for connect statement

The say the connect statement has to have the following form:

CONNECT TO <SQL-server> [AS <connection name>] [USER <user name>]

It is implementation dependant how to get database name, server name resp.
number and port number from SQL-server. How will we do this?

How about this?

<dbname>@<server>:<port>

Each missing entry will be set to the default value:
template1@localhost:5432.

Michael

--
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

> CONNECT TO <SQL-server> [AS <connection name>] [USER <user name>]
> How about this?
> <dbname>@<server>:<port>
> Each missing entry will be set to the default value:
> template1@localhost:5432.

Looks good, though perhaps the default db should be the user's name?

Is there any benefit to using a url-style spec?

  postgres://server:port/dbname

Very fashionable :)

                       - Tom

Thomas G. Lockhart writes:
> > Each missing entry will be set to the default value:
> > template1@localhost:5432.
>
> Looks good, though perhaps the default db should be the user's name?

Yes, of course. This example came just from me using the Debian release of
6.3 which opens template1 as default. I cannot run 6.4, so I have to test
with the old version.

I do not enter a default myself, but rather let PQsetdb handle it.

> Is there any benefit to using a url-style spec?
>
>   postgres://server:port/dbname
>
> Very fashionable :)

That looks good. But to be really usefule I think we should add both ways
not only to ecpg, but to psql as well.

How about a adding the parser code for both to PQsetdb so we can do:

PQsetdeb(NULL,NULL,NULL,NULL,"postgres://server:port/dbname")

and

PQsetdeb(NULL,NULL,NULL,NULL,"dbname@server:port")

as synonym for

PQsetdb(server,port,NULL,NULL,dbname)?

Michael


--
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

Michael Meskes wrote:
>
> The say the connect statement has to have the following form:
>
> CONNECT TO <SQL-server> [AS <connection name>] [USER <user name>]
>
> It is implementation dependant how to get database name, server name resp.
> number and port number from SQL-server. How will we do this?

I use <server>:<port> as <SQL-server> and a separate SET SCHEMA <name>
to set the database name as (I think) this is more consistent with
SQL/2.

Phil

Phil Thompson writes:
> I use <server>:<port> as <SQL-server> and a separate SET SCHEMA <name>
> to set the database name as (I think) this is more consistent with
> SQL/2.

I don't think I like this:

 12.3  <set schema statement>

         Function

         Set the default schema name for unqualified <schema qualified
         name>s in <preparable statement>s that are prepared in the
         current SQL-session by an <execute immediate statement> or a
         <prepare statement> and in <direct SQL statement>s that are invoked
         directly.

...

So it means I have to do the following to really connect:

    exec sql connect to server;
    exec sql set scheme template1;

This only makes sense IMO if we support different schemes over one
connection. but we don't do this, do we?

Michael
--
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10