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 c
(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 i
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
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 i
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
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
standa
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 usin
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 th
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, i
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
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
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 th
12 matches
Mail list logo
