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])
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
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
.
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]
? 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
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
, volunteers?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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
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
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]
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
.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
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
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
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
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
it?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
?
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
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
;-)
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
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
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
. 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
puts up with the overhead
of MULTIBYTE support.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
. 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
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
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
27 matches
Mail list logo
