Tom Lane writes:
> (BTW, I should think that iconv or some related tool would have a
> solution for fixing this miscoding; it's not an uncommon problem.)
I guess recode is handling that.
http://recode.progiciels-bpi.ca/manual/Universal.html#Universal
Regards,
--
dim
--
Sent via pgsql-bugs
The following bug has been logged online:
Bug reference: 5542
Logged by: Roman
Email address: zo...@oe-it.ru
PostgreSQL version: 9.0
Operating system: Win7 x64
Description:Query optimization problem
Details:
I have a query:
SELECT d1.ID, d2.ID
FROM DocPrimary d1
Not 100% sure I have a bug, but I've never seen this before so I
though it was worth a post. Confirmed on 8.4.4 and 9.0 beta. I have
a small self contained test case that I can send off line or on the
list following some code obfuscation (it's fairly complex to set up).
merlin
--
Sent via pgs
The following bug has been logged online:
Bug reference: 5543
Logged by: Ranga Gopalan
Email address: ranga_gopa...@hotmail.com
PostgreSQL version: 8.4.4
Operating system: Linux x86-64
Description:Poor performance - Index scan backwards not used for
order by desc with
Merlin Moncure writes:
> Not 100% sure I have a bug, but I've never seen this before so I
> though it was worth a post. Confirmed on 8.4.4 and 9.0 beta.
So let's see the test case ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
On 06/07/10 14:43, Roman wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5542
> Logged by: Roman
> Email address: zo...@oe-it.ru
> PostgreSQL version: 9.0
> Operating system: Win7 x64
> Description:Query optimization problem
> Details:
On the
I have an IRC logger storing its data in a Postgres 8.3.3. The table in
question has the interesting column declared as:
time timestamp with time zone default now()
The logger uses a prepared statement to insert data, and does not mention
this column in the INSERT statement, hence the assumption
Gurjeet Singh writes:
> I ran the following query, and got an unexpected negative value. Does this
> imply that SELECT-transaction was able to see a row created by
> INSERT-transaction which started after the SELECT-transaction?
Was the SELECT inside a BEGIN block?
regard
On Wed, Jul 7, 2010 at 12:18 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > I ran the following query, and got an unexpected negative value. Does
> this
> > imply that SELECT-transaction was able to see a row created by
> > INSERT-transaction which started after the SELECT-transaction?
>
> Was
On Wed, Jul 7, 2010 at 12:18 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > I ran the following query, and got an unexpected negative value. Does
> this
> > imply that SELECT-transaction was able to see a row created by
> > INSERT-transaction which started after the SELECT-transaction?
>
> Was
10 matches
Mail list logo