Re: [BUGS] BUG #1862: ECPG Connect, host variable trailing blanks
>Identifiers are NAME types, not CHAR types >From the URL reference that you gave: UPDATE MY_TABLE SET A = 5; The tokens MY_TABLE and A are examples of identifiers. But I don't think it is legal SQL to state this as: UPDATE :V1 SET :V2 = 5; In other words, host variables are never considered identifiers in normal DML statements. According to the documentation at: http://www.postgresql.org/docs/8.0/static/ecpg-connect.html EXEC SQL CONNECT TO :target USER :user; The last form makes use of the variant referred to above as character variable reference. To be consistent with other uses of host variables, we request that host variables within a connect statement act like host variables in DML statements. Oracle seems to think this is the correct approach, and also "the format of the connection target is not specified in the SQL standard". Michael Fuhr <[EMAIL PROTECTED]> To 09/07/2005 12:15 James Gray <[EMAIL PROTECTED]> AM cc pgsql-bugs@postgresql.org Subject Re: [BUGS] BUG #1862: ECPG Connect, host variable trailing blanks On Tue, Sep 06, 2005 at 09:02:47PM +0100, James Gray wrote: > The problem that we are having involves a connect statement with host > variables: >EXEC SQL CONNECT TO :target AS :user > > Our problem is that we are passed Cobol strings which are blank padded. > Our string strategy works fine for Oracle, but not for Postgres CONNECTs. > > For example, if we are trying to connect to: > - database: demo > - user: scott > - password: tiger > the strings must be "demo", "scott" and "tiger". > > With trailing blanks user "scott" will not match user "scott ", > which is what we will present if the user had defined the Cobol variable as > PIC X(10). In PostgreSQL, "scott" and "scott " are distinct identifiers, and both are valid. See "Identifiers and Key Words" in the "SQL Syntax" chapter of the documentation, especially the part that discusses quoted identifiers: http://www.postgresql.org/docs/8.0/static/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS Although creating databases, users, tables, etc., with trailing spaces is probably a bad idea, PostgreSQL does allow such names, and the trailing spaces are significant. > This only applies to CONNECT host variables, since trailing blanks in a > CHAR column are ignored in comparisons for all other interactions with > Postgres. > > Since this is inconsistent behavior, and also doesn't match Oracle's > behavior, we are requesting a fix or an option. Identifiers are NAME types, not CHAR types; the difference in behavior is no more inconsistent than that between VARCHAR and CHAR. If the strings have trailing spaces but the identifiers on the server side don't, then strip the spaces on the client side. -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] Installing to Windows XP cannot create db
Hi, I have managed to install the service on my windows XP box, but when I try to create a database I get: Creating database 'test' . . . E_LQ0001 Failed to connect to DBMS session. E_LC0001 GCA protocol service (GCA_REQUEST) failure. Internal service status E_GC0135 -- A default server class has been defined (by II_GCN_SVR_TYPE), but that server class is not known to the Name Server.. Creation of database 'test' abnormally terminated. Regards Will Lewis This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. ** BNP Paribas Private Bank London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Securities Services London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Fund Services UK Limited is authorised and regulated by the Financial Services Authority.
[BUGS] BUG #1863: Install won't work
The following bug has been logged online: Bug reference: 1863 Logged by: Howard Brodale Email address: [EMAIL PROTECTED] PostgreSQL version: 8.03 Operating system: Win 98 2nd ed Description:Install won't work Details: postgresql-8.0, 56kb Wndows Installation 5/12/05 9:14AM bombs with a popup window displaying "Failed to create process: 2!" right after the language selection window. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1862: ECPG Connect, host variable trailing blanks
On Tue, Sep 06, 2005 at 09:02:47PM +0100, James Gray wrote: > The problem that we are having involves a connect statement with host > variables: >EXEC SQL CONNECT TO :target AS :user > > Our problem is that we are passed Cobol strings which are blank padded. > Our string strategy works fine for Oracle, but not for Postgres CONNECTs. > > For example, if we are trying to connect to: > - database: demo > - user: scott > - password: tiger > the strings must be "demo", "scott" and "tiger". > > With trailing blanks user "scott" will not match user "scott ", > which is what we will present if the user had defined the Cobol variable as > PIC X(10). In PostgreSQL, "scott" and "scott " are distinct identifiers, and both are valid. See "Identifiers and Key Words" in the "SQL Syntax" chapter of the documentation, especially the part that discusses quoted identifiers: http://www.postgresql.org/docs/8.0/static/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS Although creating databases, users, tables, etc., with trailing spaces is probably a bad idea, PostgreSQL does allow such names, and the trailing spaces are significant. > This only applies to CONNECT host variables, since trailing blanks in a > CHAR column are ignored in comparisons for all other interactions with > Postgres. > > Since this is inconsistent behavior, and also doesn't match Oracle's > behavior, we are requesting a fix or an option. Identifiers are NAME types, not CHAR types; the difference in behavior is no more inconsistent than that between VARCHAR and CHAR. If the strings have trailing spaces but the identifiers on the server side don't, then strip the spaces on the client side. -- Michael Fuhr ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
