[BUGS] BUG #1945: pgAdmin Crash when adding user
The following bug has been logged online: Bug reference: 1945 Logged by: Bernard Simmons Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Beta 2 Operating system: Windows 2000 Professional SP4 Description:pgAdmin Crash when adding user Details: I was able to crash pgAdmin III when I attempted to add a Login Role. Specifics: RoleName: GoodSteward Password: goodsteward Expiries: (Tried a blank date and 10/5/2006) Role Privileges: Selected them all. Generates: Application Error Dialog Box The Instruction at "0x0040dc66" referenced memory at "0x002c". The memory could not be "read". Pressing ok generates 3 more Application Error Dialog Box messages before the program exits. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1946: Service registration fault during upgrade installation
The following bug has been logged online: Bug reference: 1946 Logged by: Pedro Alvarez Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: Windows XP SP2 Description:Service registration fault during upgrade installation Details: During upgrade from 8.0.3 to 8.0.4 installation procedure doesn't care about your database location and set it to default. In that case your server won't start until manual repaire. Steps to reproduce: prerequisities) Have a running version (e.g 8.0.3 or any which can be upgraded by latest setup), using different database location path, using NT Service for startup 1) Start upgrade by upgrade.bat 2) Try to start service 3) Check service setting in Service console ---(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
Re: [BUGS] BUG #1937: Parts of information_schema only accessible
Is this something we need to patch? --- Stephan Szabo wrote: > On Tue, 4 Oct 2005, Tony Marston wrote: > > > Description:Parts of information_schema only accessible to owner > > Details: > > > > I have been trying to access parts of the information_schema as an ordinary > > user, not as owner, and I am encountering instances where I cannot retrieve > > any rows at all, or where some of the columns are empty when they should not > > be. > > > > This sounds like a faulty implementation to me, with too many restrictions. > > As far as I am concerned if I have access privileges on an object then I > > should be able to see ALL information_schema details regarding that object. > > Complain to the SQL committee then. ;) Many portions of information_schema > are defined in the spec with limitations based on the user. > > > As an example, in the view "information_schema.columns" I can only see the > > entry in COLUMN_DEFAULT if I am the owner. Why is this? What is the logic > > behind this decision? > > Because of this piece of the definition: > > CASE WHEN EXISTS ( SELECT * >FROM DEFINITION_SCHEMA.SCHEMATA AS S >WHERE ( TABLE_CATALOG, TABLE_SCHEMA ) >= (S.CATALOG_NAME, S.SCHEMA_NAME ) > AND SCHEMA_OWNER = USER ) > THEN COLUMN_DEFAULT > ELSE NULL > END AS COLUMN_DEFAULT, > > It looks like we're using table owner rather than schema owner since we > allow mixed ownership of contents of a schema, but the general principle > is the same. > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1945: pgAdmin Crash when adding user
Bernard Simmons wrote: The following bug has been logged online: Bug reference: 1945 Logged by: Bernard Simmons Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Beta 2 Operating system: Windows 2000 Professional SP4 Description:pgAdmin Crash when adding user Details: I was able to crash pgAdmin III when I attempted to add a Login Role. Which pgAdmin version is that? I can't reproduce this with pgAdmin 1.4Beta1. Please post reply and further pgAdmin related stuff to pgadmin-support. Regards, Andreas ---(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
Re: [BUGS] BUG #1937: Parts of information_schema only accessible
On Sat, 8 Oct 2005, Tony Marston wrote: > > > > > > -Original Message- > > From: Stephan Szabo [mailto:[EMAIL PROTECTED] > > Sent: 08 October 2005 16:44 > > To: Tony Marston > > Subject: RE: [BUGS] BUG #1937: Parts of information_schema > > only accessible to owner > > > > > > On Sat, 8 Oct 2005, Tony Marston wrote: > > > > > I have searched through the SQL 2003 standard and can find no such > > > restriction. In the volume titled "Information and > > Definition Schemas > > > (SQL/Schemata)" in section 5.20 (INORMATON_SCHEMA.COLUMNS view) it > > > states the following under the heading "Function": > > > > > > "Identify the columns of tables defined in this catalog that are > > > accessible to a given user or role." > > > > > > Note there that it does not say that the user must be the > > owner, but > > > that the user is allowed to access the table (i.e. has access > > > privileges). > > > > > > I take this to mean (as any reasonable person would) that if a user > > > has been granted the privilges to access an object then > > that same user > > > can view all the information on that object which is defined within > > > the information schema. > > > > > > Unless you can provide a direct quote from the SQL standard which > > > contradicts this I strongly suggest that you revise your opinion. > > > > What I gave was *directly* part of the definition of the view from the > > standard: > > > > > > CASE WHEN EXISTS ( SELECT * > > > >FROM DEFINITION_SCHEMA.SCHEMATA AS S > > > >WHERE ( TABLE_CATALOG, TABLE_SCHEMA ) > > > >= (S.CATALOG_NAME, S.SCHEMA_NAME ) > > > > AND SCHEMA_OWNER = USER ) > > > > THEN COLUMN_DEFAULT > > > > ELSE NULL > > > > END AS COLUMN_DEFAULT, > > > > I think any "reasonable person" would read the definition > > portion above from that view and interpret that as give the > > column default if the table the the column is in came from a > > schema that is owned by USER otherwise give NULL. > > > > I disagree. The function description in the SQL 1999 standard says "Identify > the columns of tables defined in this catalog that are accessible to a given > user." It is clear that the actual code sample given does not conform to > this description, so I would argue that the code is wrong and the > description is right. Any reasonable person would assume that the code > sample would conform to the description. After all, the description does not > say "except for those items where the user must also be the owner". If there's two items: "Function" with a description and "Definition" with a definition, I think it's fairly ignorant to read the former as overriding the latter. The latter *is* the definition. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1937: Parts of information_schema only accessible
Bruce Momjian wrote: > > Is this something we need to patch? As soon as we get 50% votes on the SQL committee ... -- Alvaro Herrera Architect, http://www.EnterpriseDB.com "No necesitamos banderas No reconocemos fronteras" (Jorge González) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1937: Parts of information_schema only accessible to owner
Tony Marston wrote: > I have searched through the SQL 2003 standard and can find no such > restriction. In the volume titled "Information and Definition Schemas > (SQL/Schemata)" in section 5.20 (INORMATON_SCHEMA.COLUMNS view) it > states the following under the heading "Function": > > "Identify the columns of tables defined in this catalog that are > accessible to a given user or role." The information schema currently follows SQL 1999. Interestingly, the requirement to "blank out" the column defaults of non-owned tables was apparently dropped in SQL 2003. Clearly, we need to review the information schema for SQL 2003 conformance. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1937: Parts of information_schema only accessible
On Sat, 8 Oct 2005, Tony Marston wrote: > > > > If there's two items: > > "Function" with a description and "Definition" with a > > definition, I think it's fairly ignorant to read the former > > as overriding the latter. The latter *is* the definition. > > > > Yes, but if the sample code disagrees with the description shouldn't you at > least ask someone in authority which one is right? Shouldn't you ask WHY It's not sample code. It's a definition. If a description doesn't match a definition, generally the definition wins and it's the description that's wrong. > some parts of the information schema should only be accessible if you are > the owner when 99% of the information schema does NOT have this restriction? Why would this be any more consistent than anywhere else in SQL? And they use this same restriction in ATTRIBUTES as well (but not in DOMAINS). > Nowhere in any function descriptions does it say that the user must be the > owner, so clearly whoever wrote the sample code made a minor mistake, and Let's see, "Identify the assertions defined in this catalog that are owned by a given user", "Identify the check constraints defined in this catalog that are owned by a given user", "Identify the columns that are dependent on a domain defined in this catalog and owned by a user", ... ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #1947: Enhancement Request - CONCAT() function
The following bug has been logged online: Bug reference: 1947 Logged by: Tony Marston Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Windows XP Description:Enhancement Request - CONCAT() function Details: I would like the option to use CONCAT(field1, ' ', field2) instead of the vertical bar syntax (field1 || ' ' || field2) as this is also available in other popular databases (MySQL, ORACLE). I am trying to develop applications which are daabase independent, so the use of common SQL syntax is very important. ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #1948: Enhancement Request - INSERT syntax
The following bug has been logged online: Bug reference: 1948 Logged by: test_autoincrement Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Windows XP Description:Enhancement Request - INSERT syntax Details: Currently the INSERT statement requires field names and field values to be presented in separate lists whereas the UPDATE statement requires each field and value to be presented in a single string (name='value'). The latter is more usable because if there is any validation failure with a field it is easy to track down down the value in the query sting that goes with a particular field name. Compare this with a failure on an INSERT statement containing a large number of fields - you have to count through the first list to get the index number of the field name, then you have to count through the list of values to identify the one which goes with that field name. This is not user-friendly, and I think the SQL committee made a big mistake in defining totally different structures for the INSERT and UPDATE statements. MySQL already offers this option, so why can't you? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1937: Parts of information_schema only accessible to owner
> -Original Message- > From: Stephan Szabo [mailto:[EMAIL PROTECTED] > Sent: 08 October 2005 16:44 > To: Tony Marston > Subject: RE: [BUGS] BUG #1937: Parts of information_schema > only accessible to owner > > > On Sat, 8 Oct 2005, Tony Marston wrote: > > > I have searched through the SQL 2003 standard and can find no such > > restriction. In the volume titled "Information and > Definition Schemas > > (SQL/Schemata)" in section 5.20 (INORMATON_SCHEMA.COLUMNS view) it > > states the following under the heading "Function": > > > > "Identify the columns of tables defined in this catalog that are > > accessible to a given user or role." > > > > Note there that it does not say that the user must be the > owner, but > > that the user is allowed to access the table (i.e. has access > > privileges). > > > > I take this to mean (as any reasonable person would) that if a user > > has been granted the privilges to access an object then > that same user > > can view all the information on that object which is defined within > > the information schema. > > > > Unless you can provide a direct quote from the SQL standard which > > contradicts this I strongly suggest that you revise your opinion. > > What I gave was *directly* part of the definition of the view from the > standard: > > > > CASE WHEN EXISTS ( SELECT * > > >FROM DEFINITION_SCHEMA.SCHEMATA AS S > > >WHERE ( TABLE_CATALOG, TABLE_SCHEMA ) > > >= (S.CATALOG_NAME, S.SCHEMA_NAME ) > > > AND SCHEMA_OWNER = USER ) > > > THEN COLUMN_DEFAULT > > > ELSE NULL > > > END AS COLUMN_DEFAULT, > > I think any "reasonable person" would read the definition > portion above from that view and interpret that as give the > column default if the table the the column is in came from a > schema that is owned by USER otherwise give NULL. > I disagree. The function description in the SQL 1999 standard says "Identify the columns of tables defined in this catalog that are accessible to a given user." It is clear that the actual code sample given does not conform to this description, so I would argue that the code is wrong and the description is right. Any reasonable person would assume that the code sample would conform to the description. After all, the description does not say "except for those items where the user must also be the owner". Tony Marston http://www.tonymarston.net ---(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
Re: [BUGS] BUG #1937: Parts of information_schema only accessible to owner
> -Original Message- > From: Stephan Szabo [mailto:[EMAIL PROTECTED] > Sent: 08 October 2005 18:01 > To: Tony Marston > Cc: pgsql-bugs@postgresql.org > Subject: RE: [BUGS] BUG #1937: Parts of information_schema > only accessible to owner > > > > On Sat, 8 Oct 2005, Tony Marston wrote: > > > > > > > > > > > > -Original Message- > > > From: Stephan Szabo [mailto:[EMAIL PROTECTED] > > > Sent: 08 October 2005 16:44 > > > To: Tony Marston > > > Subject: RE: [BUGS] BUG #1937: Parts of information_schema only > > > accessible to owner > > > > > > > > > On Sat, 8 Oct 2005, Tony Marston wrote: > > > > > > > I have searched through the SQL 2003 standard and can > find no such > > > > restriction. In the volume titled "Information and > > > Definition Schemas > > > > (SQL/Schemata)" in section 5.20 > (INORMATON_SCHEMA.COLUMNS view) it > > > > states the following under the heading "Function": > > > > > > > > "Identify the columns of tables defined in this catalog > that are > > > > accessible to a given user or role." > > > > > > > > Note there that it does not say that the user must be the > > > owner, but > > > > that the user is allowed to access the table (i.e. has access > > > > privileges). > > > > > > > > I take this to mean (as any reasonable person would) that if a > > > > user has been granted the privilges to access an object then > > > that same user > > > > can view all the information on that object which is defined > > > > within the information schema. > > > > > > > > Unless you can provide a direct quote from the SQL > standard which > > > > contradicts this I strongly suggest that you revise > your opinion. > > > > > > What I gave was *directly* part of the definition of the > view from > > > the > > > standard: > > > > > > > > CASE WHEN EXISTS ( SELECT * > > > > >FROM DEFINITION_SCHEMA.SCHEMATA AS S > > > > >WHERE ( TABLE_CATALOG, TABLE_SCHEMA ) > > > > >= (S.CATALOG_NAME, S.SCHEMA_NAME ) > > > > > AND SCHEMA_OWNER = USER ) > > > > > THEN COLUMN_DEFAULT > > > > > ELSE NULL > > > > > END AS COLUMN_DEFAULT, > > > > > > I think any "reasonable person" would read the definition portion > > > above from that view and interpret that as give the > column default > > > if the table the the column is in came from a schema that > is owned > > > by USER otherwise give NULL. > > > > > > > I disagree. The function description in the SQL 1999 standard says > > "Identify the columns of tables defined in this catalog that are > > accessible to a given user." It is clear that the actual > code sample > > given does not conform to this description, so I would > argue that the > > code is wrong and the description is right. Any reasonable person > > would assume that the code sample would conform to the description. > > After all, the description does not say "except for those > items where > > the user must also be the owner". > > If there's two items: > "Function" with a description and "Definition" with a > definition, I think it's fairly ignorant to read the former > as overriding the latter. The latter *is* the definition. > Yes, but if the sample code disagrees with the description shouldn't you at least ask someone in authority which one is right? Shouldn't you ask WHY some parts of the information schema should only be accessible if you are the owner when 99% of the information schema does NOT have this restriction? Nowhere in any function descriptions does it say that the user must be the owner, so clearly whoever wrote the sample code made a minor mistake, and you are perpetuationg that mistake. Which is the most logical answer? Any user with privileges or no-one but the owner? If you were to ask 10 different developers for their opinion on this subject how many would agree with you and how many would agree with me? Tony Marston http://www.tonymarston.net ---(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
Re: [BUGS] BUG #1948: Enhancement Request - INSERT syntax
On Sat, Oct 08, 2005 at 12:49:58PM +0100, test_autoincrement wrote: > This is not user-friendly, and I think the SQL committee made a big mistake > in defining totally different structures for the INSERT and UPDATE > statements. Matter of opinion. > MySQL already offers this option, so why can't you? MySQL also thinks it's OK to truncate data. Comparing PostgreSQL to them isn't a very good way to go about getting a feature added. Ultimately, I highly doubt that anyone on -hackers has any interest in this, so it's very unlikely to get done unless you do it yourself (or pay someone to do it). Even then I suspect -hackers might reject it. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
"Tony Marston" <[EMAIL PROTECTED]> writes: > I would like the option to use CONCAT(field1, ' ', field2) instead of the > vertical bar syntax (field1 || ' ' || field2) as this is also available in > other popular databases (MySQL, ORACLE). || is the SQL standard, CONCAT() is not. But feel free to write your own functions: create function concat(text,text) returns text as 'select $1 || $2' language sql strict immutable; create function concat(text,text,text) returns text as 'select $1 || $2 || $3' language sql strict immutable; ... repeat up to whatever number of parameters seems needed ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1937: Parts of information_schema only accessible to owner
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The information schema currently follows SQL 1999. Interestingly, the > requirement to "blank out" the column defaults of non-owned tables was > apparently dropped in SQL 2003. Clearly, we need to review the > information schema for SQL 2003 conformance. Yeah. Not only that, but they changed the WHERE clause: where formerly it restricted you to seeing tables you own, it now allows you to see anything you have any granted privileges on. SQL99 reads WHERE (C.TABLE_CATALOG, C.TABLE_SCHEMA, C.TABLE_NAME, C.COLUMN_NAME) IN (SELECT TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME FROM DEFINITION_SCHEMA.COLUMN_PRIVILEGES WHERE (SCHEMA_OWNER IN ( 'PUBLIC', CURRENT_USER ) OR SCHEMA_OWNER IN ( SELECT ROLE_NAME FROM ENABLED_ROLES ))) but what I see in 2003 is WHERE (C.TABLE_CATALOG, C.TABLE_SCHEMA, C.TABLE_NAME, C.COLUMN_NAME) IN (SELECT CP.TABLE_CATALOG, CP.TABLE_SCHEMA, CP.TABLE_NAME, CP.COLUMN_NAME FROM DEFINITION_SCHEMA.COLUMN_PRIVILEGES AS CP WHERE (CP.GRANTEE IN ( 'PUBLIC', CURRENT_USER ) OR CP.GRANTEE IN ( SELECT ROLE_NAME FROM ENABLED_ROLES ))) Probably there are similar changes in other views. Not sure if there's time to do this for 8.1 ... I don't really have time to grovel through it, do you? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
On Sat, Oct 08, 2005 at 12:39:40PM +0100, Tony Marston wrote: > > The following bug has been logged online: > > Bug reference: 1947 > Logged by: Tony Marston > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.3 > Operating system: Windows XP > Description:Enhancement Request - CONCAT() function > Details: > > I would like the option to use CONCAT(field1, ' ', field2) instead > of the vertical bar syntax (field1 || ' ' || field2) as this is also > available in other popular databases (MySQL, ORACLE). I am trying to > develop applications which are daabase independent, so the use of > common SQL syntax is very important. Fix your application so that it uses the SQL standard ||, which Oracle supports and MySQL can be made to support via a runtime option. Also, before deciding that you must support multiple back-end databases, please look over this presentation http://www.powerpostgresql.com/Downloads/database_depends_public.swf and see whether this is really a road you want to travel. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > And you might want to make it a project at http://pgfoundry.org so > others can make use of it. You might also want to define it as accepting > an array; I think that would allow you to accept any number of > parameters. I think Tony is trying to avoid putting in any actual work ;-). To me, the sanest change would be to modify his app to use the SQL-standard syntax. Which surely is supported by those other databases too, no? And if not, why are *we* the ones getting the bug report? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
On Sat, Oct 08, 2005 at 04:33:10PM -0400, Tom Lane wrote: > "Tony Marston" <[EMAIL PROTECTED]> writes: > > I would like the option to use CONCAT(field1, ' ', field2) instead of the > > vertical bar syntax (field1 || ' ' || field2) as this is also available in > > other popular databases (MySQL, ORACLE). > > || is the SQL standard, CONCAT() is not. But feel free to write your > own functions: > > create function concat(text,text) returns text as > 'select $1 || $2' language sql strict immutable; > create function concat(text,text,text) returns text as > 'select $1 || $2 || $3' language sql strict immutable; > ... repeat up to whatever number of parameters seems needed ... And you might want to make it a project at http://pgfoundry.org so others can make use of it. You might also want to define it as accepting an array; I think that would allow you to accept any number of parameters. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
On Sat, Oct 08, 2005 at 11:11:58PM +0100, Tony Marston wrote: > > > -Original Message- > > > > > > The following bug has been logged online: > > > > > > Bug reference: 1947 > > > Logged by: Tony Marston > > > Email address: [EMAIL PROTECTED] > > > PostgreSQL version: 8.0.3 > > > Operating system: Windows XP > > > Description:Enhancement Request - CONCAT() function > > > Details: > > > > > > I would like the option to use CONCAT(field1, ' ', field2) > > > instead of the vertical bar syntax (field1 || ' ' || field2) as > > > this is also available in other popular databases (MySQL, > > > ORACLE). I am trying to develop applications which are daabase > > > independent, so the use of common SQL syntax is very important. > > > > Fix your application so that it uses the SQL standard ||, > > Not until you fix your product so that it follows the current SQL > standard TO THE LETTER and contains NOTHING which is not in the > standard! In case you did not know, PostgreSQL Global Development Group is an all-volunteer organization. If you have something constructive to contribute, please feel free to mention it, but please also to recall that PGDG does not owe you anything, and whinging about how we use a common, standard thing rather than a rare, non-standard thing is going to get you somewhere between nothing and negative. People will remember your contributions, for good or ill. So far, it's for ill. > It is a well-known fact that every database vendor includes their > own "extensions" to the SQL standard simply because they want to > offer more functionality to their users, and they can't wait for it > to be formally documented in the standard. It is also a well known > fact that extensions made by one database vendor may also be adopted > by other vendors in order to maintain a level of compatibility. This is not one of those cases. > Are you honestly going to tell me that if your user base requested > certain additional functionality that you would refuse to include it > simply because it was "not in the standard"? Several proposals have been rejected because they violated the standard. This is why there is no CONNECT BY syntax for trees, but there will be a WITH RECURSIVE syntax at some point. Regards, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
> -Original Message- > From: David Fetter [mailto:[EMAIL PROTECTED] > Sent: 08 October 2005 22:16 > To: Tony Marston > Cc: pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function > > > On Sat, Oct 08, 2005 at 12:39:40PM +0100, Tony Marston wrote: > > > > The following bug has been logged online: > > > > Bug reference: 1947 > > Logged by: Tony Marston > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 8.0.3 > > Operating system: Windows XP > > Description:Enhancement Request - CONCAT() function > > Details: > > > > I would like the option to use CONCAT(field1, ' ', field2) > instead of > > the vertical bar syntax (field1 || ' ' || field2) as this is also > > available in other popular databases (MySQL, ORACLE). I am > trying to > > develop applications which are daabase independent, so the use of > > common SQL syntax is very important. > > Fix your application so that it uses the SQL standard ||, Not until you fix your product so that it follows the current SQL standard TO THE LETTER and contains NOTHING which is not in the standard! It is a well-known fact that every database vendor includes their own "extensions" to the SQL standard simply because they want to offer more functionality to their users, and they can't wait for it to be formally documented in the standard. It is also a well known fact that extensions made by one database vendor may also be adopted by other vendors in order to maintain a level of compatibility. Are you honestly going to tell me that if your user base requested certain additional functionality that you would refuse to include it simply because it was "not in the standard"? If every database vendor offered nothing but the SQL standard there would be nothing to differentiate between them, so you would not be able to say "ou daabas is better than theirs beause..." > which Oracle supports and MySQL can be made to support via a > runtime option. They also both support CONCAT() because there are sometimes difficulties in dealing with vertical bars in the character sets used by certain operating systems and file systems. If enough database vendors offer it then it becmes a "de facto" standard. Tony Marston http://www.tonymarston.net ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
Tony Marston wrote: > It is a well-known fact that every database vendor includes their own > "extensions" to the SQL standard simply because they want to offer more > functionality to their users, and they can't wait for it to be formally > documented in the standard. On the other hand, it would be extremely stupid to include every syntax for every little feature. If a feature is defined by the standard, then it's quite clear which syntax to support. The fact that other vendor's product use a different, non-standard syntax, does not mean that we should too. In places where it's useful to extend the standard to offer additional features, we do so. If it's only going to clutter our namespace, we don't. Also, PostgreSQL is extensible, which is a feature not all DBMSs offer. So you can create your own CONCAT() function if you wanted. Last but not least, We have a very loyal userbase; there's no need for us to force "vendor lock-in" by supporting non-standard syntax for silly features, like other vendors do. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 17.7", W 73º 14' 26.8" "Find a bug in a program, and fix it, and the program will work today. Show the program how to find and fix a bug, and the program will work forever" (Oliver Silfridge) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
