Re: [BUGS] BUG #5637: JDBC driver method setClob always uses getAsciiStream()
On Thu, 2 Sep 2010, Jochen Terstiege wrote: The following bug has been logged online: Bug reference: 5637 Description:JDBC driver method setClob always uses getAsciiStream() Details: Using driver: postgresql-8.4-701.jdbc3.jar The method setClob() in the AbstractJdbc2Statement calls the method getAsciiStream() on the provided Clob. This leads to problems if the given Clob contains an UTF-8 encoded string. Should the driver call getCharacterStream() instead? Can this problem be solved in a different way? The issue here is that postgresql doesn't have a real Clob type on the server, only a Blob type (and even that has some quirks). So the JDBC driver allows you to retrieve a large object as either a Blob or a Clob. This means that the data the driver gets is a simple binary stream with no encoding information. The JDBC driver uses getAsciiStream because it returns an InputStream which does not have to deal with encoding conversion which could fail because it doesn't know the source data's encoding. This is important so that it can faithfully reproduce an arbitrary PG Clob. Your complaint is that this doesn't work when passed a non-PG Clob. I suppose we could try to inspect the Clob to determine if it was a PG Clob or not and choose different methods based on that determination. Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5640: ODBC driver installed but not found
(2010/09/03 3:36), Hannu Pohjanpalo wrote: The following bug has been logged online: Bug reference: 5640 Logged by: Hannu Pohjanpalo Email address: hannu.pohjanp...@winware.fi PostgreSQL version: 8.4.4 Operating system: Windows 7 Pro 64 bit Description:ODBC driver installed but not found Details: I installed PostgreSQL 8.4.4 in my Windows 7 Professional (64 bit), and ran (as Administrator)Application Stack Builder to download and install the ODBC driver. This installation looked perfectly successful, but when starting Control Panel / Administrative Tasks / ODBC Settings, and press Add..., I cannot find this PostgreSQL ODBC driver, I can only see two SQLServer drivers. I uninstalled and tried again: same result. Have you seen this before? All ideas are welcome, thanks! Please look at http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/psqlodbc/psqlodbc/docs/faq.html?rev=1.10&content-type=text/html . You can find a FAQ 6.8) Installing psqlODBC on 64bit Windows. regards, Hiroshi Inoue -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5633: an empty row with null-like values in not-null field
On Sun, Aug 29, 2010 at 8:10 PM, tkim wrote: > > The following bug has been logged online: > > Bug reference: 5633 > Logged by: tkim > Email address: kth...@gmail.com > PostgreSQL version: 9.0 beta 4 > Operating system: windows 7 professional > Description: an empty row with null-like values in not-null field > Details: > > After inserting a lot of data into a partitioned table, i found a weird > thing. When I query the table, i can see an empty row with null-like values > in 'not-null' fields. > > To show you guys the captured image, i think it's good to link my question > on StackOverflow website. > > http://stackoverflow.com/questions/3597000/postgresql-9-0-an-empty-row-with- > null-like-values-in-not-null-field Can you send us the results of: pg_dump -t st_daily2 and the results of doing this in psql: \d st_daily2 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
If you're going to use something which is PostgreSQL-specific, you may as well write your own views or use the "native" tables and views directly. I wish I could write portable code, if possible:-) I'm basically writing views on top of the information_schema under the assumption that what is expected to be a key is a key. The information schema is *useless* otherwise as wrong tuples are built on join, and derived information is not reliable. I guess I must the only actual user of the information_schema, and it will soon be back to zero user, which will be fine from the developers point of view. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS (resent)
If you're going to use something which is PostgreSQL-specific, you may as well write your own views or use the "native" tables and views directly. I wish I could write portable code, if possible:-) I'm basically writing views on top of the information_schema under the assumption that what is expected to be a key is a key. The information schema is *useless* otherwise as wrong tuples are built on join, and derived information is not reliable. I guess I must the only actual user of the information_schema, and it will soon be back to zero user, which will be fine from the developers point of view. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Maybe you shouldn't be using the information_schema in the first place. Sure, I could write non standard code for every database instead of trying to write a portable code which work on all of them directly:-) I think that trying to do the portable way, under the assumption that the standard implementation would be okay, was a reasonnable choice, even if proved wrong afterwards. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Alvaro Herrera writes: > Excerpts from Fabien COELHO's message of vie sep 03 13:39:19 -0400 2010: >> I tried to explained that I'm analyzing other people's schemas. I cannot >> ask all other people on the planet to rewrite their schemas, I pick them >> as they are. > Maybe you shouldn't be using the information_schema in the first place. It would probably be reasonable to put something into chapter 34 of the docs pointing out this limitation. I'm not sure exactly where though. Should we invent a "compatibility issues" section in that chapter, analogous to the ones we have for individual SQL commands? Are there other issues worth documenting for the information_schema views? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Excerpts from Fabien COELHO's message of vie sep 03 13:39:19 -0400 2010: > I tried to explained that I'm analyzing other people's schemas. I cannot > ask all other people on the planet to rewrite their schemas, I pick them > as they are. Maybe you shouldn't be using the information_schema in the first place. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Well, one must choose between to evil: Yeah, exactly. I think that the current tradeoff is just fine. Hmmm. I think exactly the contrary. There is no point in having a non reliable feature. ISTM that very few people use the information schema, and if the query results is not reliable, it will stay this way. If you have zero user, no one will complain, which prooves that everything is fine:-) QED. By the way, do you use the information schema? If you want SQL-standard behavior, pick SQL-standard constraint names, and there you are. I tried to explained that I'm analyzing other people's schemas. I cannot ask all other people on the planet to rewrite their schemas, I pick them as they are. Could you register this "bug" somewhere please? Thanks for your time. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Tom Lane wrote: > Yeah, exactly. I think that the current tradeoff is just fine. > If you want SQL-standard behavior, pick SQL-standard constraint > names, and there you are. I see that as the crux if it -- the current implementation *allows* standard-conforming behavior, even though it doesn't *enforce* conforming naming. The proposed alternative does not allow standard-conforming behavior. If you're going to use something which is PostgreSQL-specific, you may as well write your own views or use the "native" tables and views directly. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Fabien COELHO writes: >> Note that (2) fails for long names; you have to do something to >> compress to NAMEDATALEN. > Indeed. > What if the type is changed to TEXT? It is just a view after all. > How important is it to stick to "sql_identifier"? It's a view defined by the SQL standard, and one of the properties defined by the standard is the type of that column. > Well, one must choose between to evil: Yeah, exactly. I think that the current tradeoff is just fine. If you want SQL-standard behavior, pick SQL-standard constraint names, and there you are. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Dear Tom, Still for the sake of argument: Note that (2) fails for long names; you have to do something to compress to NAMEDATALEN. Indeed. What if the type is changed to TEXT? It is just a view after all. How important is it to stick to "sql_identifier"? The big problem with either of these is that it's no longer easily possible to extract the actual constraint name from the view. Sure. A function is provided to do so, say information_schema_constraint_name_to_pg_constraint_name. In any case, I am fairly sure that not having the constraint_name column show the actual constraint name is a violation of the spirit of the SQL spec, whether or not you can claim that it meets the letter. Well, one must choose between to evil: (1) the constraint_name is changed in the view to be unique as expected by the spec, and the data can be joined meaningfully, and some reliable information can be derived. (2) the constraint_name looks nice but is not unique, and the information in the view is ambiguous and cannot be relied upon, so one is back to square "postgresql supports the information_schema, but there is no point to query it and expecting the results to reflect the contents of the catalogs". If you want to stick to both the letter and the spirit of the spec, that would mean enforcing unique constraint names in pg and break every applications. Not good. ISTM that the "spirit" of the information schema is more to be useful (1) than to look beautiful (2). Another technical proposal, a little more subtle and with possible underlying issues I cannot foresee: have the constraint_name be a "pair of sql_identifiers". -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
