Re: [JDBC] [PATCHES] DatabaseMetadata patch
Bruce Momjian [EMAIL PROTECTED] writes: + tuple[8] = +Integer.toString((attypmod 0x) - VARHDRSZ).getBytes(); In the backend sources, we subtract VARHDRSZ *first* and then AND with . Not sure if this will ever yield a different result, but I'd say it should be kept consistent ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Ant installation (and other) issues!
Gunnar =?iso-8859-1?q?R=F8nning?= [EMAIL PROTECTED] writes: But anyway this off topic, what need to have is a build process that works nicely and I think including the ant binaries(around 500k) would be the best solution here. 500k of binaries? You just lost the argument. That's not an acceptable amount of overhead to add to the Postgres distribution. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [JDBC] NULLs and sort order
Peter Eisentraut [EMAIL PROTECTED] writes: Rene Pijlman writes: Currently the JDBC driver says: - Backend = 7.2 sorts nulls higher than any other value in a domain. In other words: ascending means nulls at the end, descending means nulls at the start. - Backend 7.2 puts nulls at the end regardless of sort order. That is correct. Actually it's more complex than that. 7.2 will provide the above-stated consistent ordering of nulls relative to non-nulls. The problem with earlier versions is that the ordering of nulls depends on what plan the optimizer chooses for the query: sorting based on a scan of a btree index would work the same as is described for 7.2, whereas sorting based on an explicit sort step would put the nulls at the end (for either ASC or DESC sort). So there was *no* consistent behavior at all in prior versions. The fix that's been applied for 7.2 is to make explicit sorts act the same as indexscans already did. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [JDBC] DatabaseMetadata problems
Rene Pijlman [EMAIL PROTECTED] writes: Reading the book Understanding the SQL standard it seems that what the standard calls a schema is a database in PostgreSQL. A catalog is a set of schemas. Following the standard, a session is supposed to have access to a catalog, but in PostgreSQL it has access to a database. Perhaps this feature has not yet been implemented because of such fundamental mapping problems. I think it'd be a mistake to expend much effort on this issue in JDBC right now. We will eventually implement SQL92-compliant schemas in the backend, and once that happens it'll be possible to do something reasonable with the catalog metadata routines in JDBC. If you try to make a half-usable implementation now, you'll just create backwards- compatibility issues for the real implementation later. So my counsel is: acknowledge that it's broken, but ignore it for now. When is eventually? Possibly 7.3, but I can't promise anything... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
chris markiewicz [EMAIL PROTECTED] writes: i do agree that since everyone isn't complaining, the problem is likely in my code. the odd thing is that i wasn't seeing this behavior with the 7.0 stuff, only with the 7.1. Hmm. Are you using the JDBC driver that was released with 7.1? That seems to have been rather buggy. You might want to grab the latest version of the driver (I forget the URL but it's been mentioned repeatedly on this list). regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [Fwd: Re: [JDBC] Using char fields with 7.1.3 driver]
[EMAIL PROTECTED] writes: Just I usually prefer using fixed field lengths as queries tend to be significantly faster. Also, you can use them in indexes. You are making assumptions based on other databases that are not relevant to Postgres. And it leads me to wonder how you would represent an ending space in a field, In varchar or text fields, trailing spaces are real data. In fixed-width char fields, trailing spaces are pads. AFAIK this is consistent with the SQL92 specification. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[JDBC] JDBC patch procedures (Re: [PATCHES] Patch for jdbc2 ResultSet.java)
Joseph Shraibman [EMAIL PROTECTED] writes: Barry Lind wrote: If you want this patch to be applied it should be sent to the pgsql-patches mail list. I thought that jdbc stuff was preferred to be on the jdbc list. I guess not. Well, patches are patches, and it's easier for the committers to spot proposed patches that go by on pgsql-patches. However, the people who are competent to review JDBC patches all seem to be hanging out on the JDBC list. Seems like there are a couple of ways that we could handle this: 1. First draft of a JDBC patch goes to JDBC list; if it passes muster there then resend to pgsql-patches for application. 2. JDBC patches go to psql-patches only, and interested JDBC people subscribe to pgsql-patches so they can kibitz. 3. We give commit privileges to one or two JDBC regulars, who take responsibility for reviewing and applying JDBC-related patches after discussion on pgsql-jdbc. (This was the old setup with Peter Mount, but he seems not to have many spare cycles for Postgres anymore.) Of these #3 seems like the solution that will emerge in the long term anyway; but do we have candidate patch-meisters now? Comments, better ideas, nominations, volunteers? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] driver source code indentation
Barry Lind [EMAIL PROTECTED] writes: I am OK with the style used for the C code. However I would like the following additional step done for the java code: replace all tabs with spaces. I disagree with this, because then we are *not* applying the same coding standards in the backend and in JDBC. If you want to propose that we dispense with tabs throughout the system, feel free to propose that --- but it was shot down last time and likely will be again. I personally concur that four-space tabs is a horrible standard, and would much rather see us using eight-space tab stops. But I haven't been able to obtain any significant consensus for that view. Some developers apparently use editors where a physical tab character needs to equal the logical indent amount... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Read transactions don't work on 7.0.x db's
Barry Lind [EMAIL PROTECTED] writes: The multiple statements in one call is there for performance reasons. Please don't remove it entirely since it works fine in 7.1 and 7.2. Instead your fix should be conditional based on server version: Given that someone else is proposing a patch that will break backward compatibility to 7.0 servers anyway, I'm unconvinced that we need this at all. Perhaps a discussion about the costs and benefits of backwards compatibility in the JDBC driver is needed --- what tradeoffs do people want to make? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Fastpath error on solaris 2.8 pgsql 7.1.3
[EMAIL PROTECTED] writes: FastPath call returned ERROR: lo_write: invalid large obj descriptor (0) Usually this indicates that you didn't have the lo_open ... lo_write ... lo_close sequence wrapped in a transaction block (BEGIN/COMMIT SQL commands). Since it's erratic for you, I'd bet that some of your application control paths have the BEGIN and some don't. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] JDBC changes for 7.2... some questions...
Ned Wolpert [EMAIL PROTECTED] writes: 1) Being able to use the RETURNING clause in prepared statements, like this INSERT INTO tableName (key1,...) VALUES (value1,...) RETURNING primKeyName INTO ? Which is what Oracle provides. INSERT ... RETURNING was discussed recently, and I think people agreed it's a good idea, but it got hung up on some unresolved issues about how it should interact with ON INSERT rules for views. Search the pghackers mailing list archives for details. At this point I think it's probably too late to consider it for 7.2, but I'm still open to doing it in 7.3 if we can come up with a bulletproof spec. regards, tom lane ---(end of broadcast)--- TIP 3: 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: [JDBC] JDBC changes for 7.2... some questions...
Ned Wolpert [EMAIL PROTECTED] writes: What about the 'select @@last_oid' to make the getInsertedOID() call available even when the driver is wrapped by a pooling manager? How do people feel about this? Yech. At least, not with *that* syntax. @@ is a valid operator name in Postgres. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Couple of patches for jdbc driver
I've mentioned it before, but I really think it would nice to decouple the release cycles of the core engine from the interfaces. Make them separate projects. We have sort of done that now by pushing everyone to the CVS version. This makes some sense to me for ODBC and JDBC, which are large and complex enough to deserve the label of separate projects; and moreover they go out of their way to work with multiple server releases. I'm not sure it's appropriate for any of the other interface libraries, though. IIRC, at one time ODBC *was* a separate project, and we decided that that wasn't working too well. Anyone recall the reasons we pulled it into the main CVS tree? Wouldn't do to make the same mistakes twice... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] JDBC pg_description update needed for CVS tip
Rene Pijlman [EMAIL PROTECTED] writes: So it appears that your new statement that uses obj_description() and col_description() returns one row with a null when there is no comment, instead of 0 rows. Is this intentional? That is how selecting a function result would work. If you don't like the behavior then we can reconsider it --- but if it's per spec then I think we should be happy. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Large Objects
Daniel Fisher [EMAIL PROTECTED] writes: I'm having some trouble inserting a large object into the database. I'm fairly certain that the problem is in my java code because I wrote some quick PHP code and it worked fine. The main problem is I'm not getting any errors, so I'm kinda stumped. The code appears to run fine, but nothing is being inserted into the database. The query trace shows that you are starting a transaction (with BEGIN) and never committing it (no COMMIT or END). So when you close the connection, the transaction is rolled back, and its effects go away. I suppose that having done conn.setAutoCommit(false), you need to add a command to explicitly commit the transaction, but I don't know JDBC well enough to know how you do that... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Connection.setCatalog()
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. I most certainly did not. According to my interpretation: I sit corrected. If you want to define catalog == database, okay with me. regards, tom lane ---(end of broadcast)--- TIP 3: 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: [JDBC] unlink large objects
Philip Crotwell [EMAIL PROTECTED] writes: I poked around in the database directory and found a file named 16948 that is 960Mb or almost all of the space on my partition. That is pg_largeobject. Vacuuming should recover the lost space; are you sure you've vacuumed it? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Password authentication failure
Paul Hart [EMAIL PROTECTED] writes: However, based on that, I would guess that the crypt() problem isn't it. As for the postmaster log file, there is nothing special in there: verify_password: password mismatch for ''. No, that tells us quite a lot: checking in the source code for that message, I can see that the backend has received your username and password, and has found the username in an external password file, and has attempted to match your password against what was in the password file. And that match didn't work. I think that crypt() is exactly where your problem is. Did you build the external password file with pg_passwd, or manually? Uhm... would that then mean that if I was on an OpenBSD machine as a client (i.e. just running psql), I would be unable (at least without massaging some code) to access a postgres instance on, say, a Solaris box? That sounds *very* fishy to me. If you use the crypt auth method (crypt on client side and send that across the wire) then yes, the crypt algorithms offered by client and server C libraries had better match. However, AFAICT you are not doing that. In the regular passwd method what we are assuming is that the crypt library routine linked into the postmaster is the same one linked into pg_passwd, or whatever program you use to maintain the flat password file. Since these are on the same machine it's not such a big assumption. Any chance we can have a standardized hashing function built into the code? Are you volunteering? There have been a couple of long discussions on pghackers about a better password challenge protocol. IIRC we came up with a good-looking paper design, but there was a notable lack of effort on actually making it happen. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Displaying/Pulling Images using JDBC ...
The Hermit Hacker [EMAIL PROTECTED] writes: Now, my thought on this is that it *sounds* like the JDBC is hitting some sort of control character is the stream that tells it to stop sending the image ... is this possible? Some binary character that needs to somehow be trapped? Embedded nulls would be the likely cause of trouble. If you're seeing OIDs in the database then the actual storage is presumably in large objects. lo_read and friends are null-safe as far as I know; probably the problem is somewhere inside the JDBC driver. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Re: [HACKERS] Outstanding patches
Bruce Momjian [EMAIL PROTECTED] writes: Has the patch that makes MOVE return number of rows actually moved (analoguous to UPDATE and DELETE) been properly submitted to patches ? I know MOVE had fixes in 7.1. I don't know of any outstanding MOVE bugs. It wasn't a bug, it was a feature ;-) Bruce did not have that patch on his list of things-to-apply, so either it was never properly submitted or it slipped through the cracks. Anyone want to dig it up and verify it against 7.1? regards, tom lane ---(end of broadcast)--- TIP 3: 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: [JDBC] Re: [HACKERS] Outstanding patches
+ /* I use CMD_UPDATE, because no CMD_MOVE or the like +exists, and I would like to provide the same +kind of info as CMD_UPDATE */ + UpdateCommandInfo(CMD_UPDATE, 0, -1*estate-es_processed); I do not think it is a good idea to return a negative count for a backwards move; that is too likely to break client code that parses command result strings and isn't expecting minus signs. The client should know whether he issued MOVE FORWARD or MOVE BACKWARDS anyway, so just returning es_processed ought to be sufficient. Otherwise I think the patch is probably OK. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] 'current' timestamp chokes jdbc driver
Joseph Shraibman [EMAIL PROTECTED] writes: If you set a timestamp field to be 'current' as per http://www.ca.postgresql.org/docs/postgres/datatype-datetime.html#AEN322 jdbc chokes on selecting that value: 'current' is deprecated and is going to go away in 7.2 anyway (that's why it's undocumented). So I'm not sure it's worth hacking JDBC to deal with it... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
MULTIBYTE and SQL_ASCII (was Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?)
[ thread renamed and cross-posted to pghackers, since this isn't only about JDBC anymore ] Barry Lind [EMAIL PROTECTED] writes: The basic issue I have it that the server is providing an API to the client to get the character encoding for the database and that API can report incorrect information to the client. I don't have any objection to changing the system so that even a non-MULTIBYTE server can store and return encoding settings. (Presumably it should only accept encoding settings that correspond to single-byte encodings.) That can't happen before 7.2, however, as the necessary changes are a bit larger than I'd care to shoehorn into a 7.1.* release. Thus I would be happy if getdatabaseencoding() returned 'UNKNOWN' or something similar when in fact it doesn't know what the encoding is (i.e. when not compiled with multibyte). I have a philosophical difference with this: basically, I think that since SQL_ASCII is the default value, you probably ought to assume that it's not too trustworthy. The software can *never* be said to KNOW what the data encoding is; at most it knows what it's been told, and in the case of a default it probably hasn't been told anything. I'd argue that SQL_ASCII should be interpreted in the way you are saying UNKNOWN ought to be: ie, it's an unspecified 8-bit encoding (and from there it's not much of a jump to deciding to treat it as LATIN1, if you're forced to do conversion to Unicode or whatever). Certainly, seeing SQL_ASCII from the server is not license to throw away data, which is what JDBC is doing now. PS. Note that if multibyte is enabled, the functionality that is being complained about here in the jdbc client is apparently ok for the server to do. If you insert a value into a text column on a SQL_ASCII database with multibyte enabled and that value contains 8bit characters, those 8bit characters will be quietly replaced with a dummy character since they are invalid for the SQL_ASCII 7bit character set. I have not tried it, but if the backend does that then I'd argue that that's a bug too. To my mind, a MULTIBYTE backend operating in SQL_ASCII encoding ought to behave the same as a non-MULTIBYTE backend: transparent pass-through of characters with the high bit set. But I'm not a multibyte guru. Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?
Barry Lind [EMAIL PROTECTED] writes: With regards to your specific problem, my guess is that you haven't created you database with the proper character set for the data you are storing in it. I am guessing you simply used the default SQL Acsii character set for your created database and therefore only the first 127 characters are defined. Any characters above 127 will be returned by java as ?'s. Does this happen with a non-multibyte-compiled database? If so, I'd argue that's a serious bug in the JDBC code: it makes JDBC unusable for non-ASCII 8-bit character sets, unless one puts up with the overhead of MULTIBYTE support. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?
Tony Grant [EMAIL PROTECTED] writes: What kind of error message does createdb -E LATIN1 give on a non MULTIBYTE backend? $ createdb -E LATIN1 foo /home/postgres/testversion/bin/createdb[143]: /home/postgres/testversion/bin/pg_encoding: not found. createdb: LATIN1 is not a valid encoding name $ Maybe there needs to be a note somewhere informing people from Europe that they too need MULTIBYTE as an option at compile time. i.e. In a bright yellow box in the HTML docs... But they *should not* need it, if they only want to use an 8-bit character set. Locale support should be enough. Or so I would think, anyway. I have to admit I have not looked very closely at the functionality that's enabled by MULTIBYTE; is any of it really needed to deal with LATINn character sets? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?
Barry Lind [EMAIL PROTECTED] writes: Now it is an easy change in the jdbc code to use LATIN1 when the server reports SQL_ASCII, but I really dislike hardcoding support that only works in english speaking countries and Western Europe. What's wrong with that? It won't be any more broken for people who are not really using LATIN1, and it will be considerably less broken for those who are. Seems like a net win to me, even without making the obvious point about where the majority of Postgres users are. It probably would be a good idea to allow the backend to store an indication of character set even when not compiled for MULTIBYTE, but that's not the issue here. To me, the issue is whether JDBC makes a reasonable effort not to munge data when presented with a backend that claims to be using SQL_ASCII (which, let me remind you, is the default setting). Converting high-bit-set characters to '?' is almost certainly NOT what the user wants you to do. Converting on the assumption of LATIN1 will make a lot of people happy, and the people who aren't happy with it will certainly not be happy with '?' conversion either. All this does is move the problem from being one that non-english countries have to being one where it is a non-english and non-western european problem (eg. Eastern Europe, Russia, etc.). Nonsense. The non-Western-European folks see broken behavior now anyway, unless they compile with MULTIBYTE and set an appropriate encoding. How would this make their lives worse, or even different? I'm merely suggesting that the default behavior could be made useful to a larger set of people than it now is, without making things any worse for those that it's not useful to. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Unable to store SHA hash (Non-HTML--Sorry)
Jerry Reid [EMAIL PROTECTED] writes:
This string contains several characters that are outside the normal ASCII
range. The string could be stored and retrieved using Oracle and MySQL, but
in Postgres any unusual characters become '?'.
Postgres will happily store anything except a null ('\0') in a text
field. I suspect that either
(a) you have set up the database with some multibyte encoding method
activated, and your funny characters are confusing the multibyte
conversions; or
(b) the mistranslation is happening on the JDBC side.
You might try enabling query logging to see exactly what command is
arriving at the backend when you try to insert this data. That should
determine whether the client or server side is at fault.
regards, tom lane
---(end of broadcast)---
TIP 3: 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
