Thread

1. Decicision needed for connect statement

   Michael Meskes <meskes@topsystem.de> — 1998-05-07T11:04:04Z

   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
   
   

2. Re: [HACKERS] Decicision needed for connect statement

   Michael Meskes <meskes@topsystem.de> — 1998-05-07T12:39:23Z

   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
   
   

3. Re: [HACKERS] Decicision needed for connect statement

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-05-07T12:39:45Z

   > 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
   
   

4. Re: [HACKERS] Decicision needed for connect statement

   Phil Thompson <phil@river-bank.demon.co.uk> — 1998-05-07T17:06:19Z

   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
   
   

5. Re: [HACKERS] Decicision needed for connect statement

   Michael Meskes <meskes@topsystem.de> — 1998-05-08T08:34:40Z

   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