>> I'm not sure that putting in to_tsvector calls there would be an
>> improvement, though, since at that point we haven't introduced
>> to_tsvector.
Uh ... wait a moment ... stop the presses. Thomas is looking at
beta1 documentation. CVS HEAD handles this a bit better I think:
http://developer.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not sure that putting in to_tsvector calls there would be an
>> improvement, though, since at that point we haven't introduced
>> to_tsvector.
>>
>> Thoughts anyone?
> Yep, I saw that chicken and egg problem in the docs when I was
Tom Lane wrote:
> "Thomas H." <[EMAIL PROTECTED]> writes:
> > i saw my mistake. i misinterpreted the examples to show the possibility
> > to convert *any* text by using casting to tsvector as an alternative to
> > using to_tsvector :)
>
> Yeah, the examples in section 12.1.2 are not actually goo
"Thomas H." <[EMAIL PROTECTED]> writes:
> i saw my mistake. i misinterpreted the examples to show the possibility
> to convert *any* text by using casting to tsvector as an alternative to
> using to_tsvector :)
Yeah, the examples in section 12.1.2 are not actually good practice:
both sides of th
there are more problems with tsvectors. this also fails:
SELECT ' just a test: 123 '::tsvector;
ERROR: syntax error in tsvector: " just a test: 123 "
That's not a bug; your input isn't valid tsvector syntax.
ok. after re-reading page
http://www.postgresql.org/docs/8.3/static/textsearch-i
"Thomas H." <[EMAIL PROTECTED]> writes:
> there are more problems with tsvectors. this also fails:
> SELECT ' just a test: 123 '::tsvector;
> ERROR: syntax error in tsvector: " just a test: 123 "
That's not a bug; your input isn't valid tsvector syntax.
regards, tom lane
"Thomas Haegi" <[EMAIL PROTECTED]> writes:
> Operating system: Windows 2003
> CREATE INDEX posts_fts_idx ON forum.posts USING gin(to_tsvector('english',
> p_msg_clean));
> ERROR: translation from wchar_t to server encoding failed: No error
Hmm. That error message is close to some code that is
the reported problem below can be reproduced by using this simple query
straight from the documentation:
SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
Works for me:
u=# set default_text_search_config = 'pg_catalog.german';
SET
u=# SELECT to_tsvector('a fat cat sat on a mat
"Thomas H." <[EMAIL PROTECTED]> writes:
> the reported problem below can be reproduced by using this simple query
> straight from the documentation:
> SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
Works for me:
u=# set default_text_search_config = 'pg_catalog.german';
SET
u=#
the reported problem below can be reproduced by using this simple query
straight from the documentation:
SELECT to_tsvector('a fat cat sat on a mat and ate a fat rat');
--> postgres.exe dies instantly, with the logs being the same as in the
bugreport.
interestingly using ::tsvector (which
The following bug has been logged online:
Bug reference: 3767
Logged by: Thomas Haegi
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3b3
Operating system: Windows 2003
Description:tsearch2 index creation fatal crash
Details:
the previously reported problem g
The following bug has been logged online:
Bug reference: 3766
Logged by: Thomas Haegi
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3b3
Operating system: Windows 2003
Description:tsearch2 index creation error
Details:
when following the documentation
(http:
>>> On Tue, Nov 20, 2007 at 3:47 PM, in message
<[EMAIL PROTECTED]>, Cade Cairns <[EMAIL PROTECTED]>
wrote:
> On 20-Nov-07, at 2:42 PM, Heikki Linnakangas wrote:
>>
>> http://www.postgresql.org/docs/8.1/interactive/datatype-bit.html
>>
>> "Note: If one explicitly casts a bit-string value to bit(
Can anyone explain why this is the case?
On 20-Nov-07, at 2:42 PM, Heikki Linnakangas wrote:
Cade Cairns wrote:
When casting a bit string constant using hexadecimal notation to a
longer
bit string, the result is padded with 0's on the right. This will
result in
inconsistent/useless results
Cade Cairns wrote:
When casting a bit string constant using hexadecimal notation to a longer
bit string, the result is padded with 0's on the right. This will result in
inconsistent/useless results:
test=# select x'ff'::integer;
int4
--
255
(1 row)
test=# select x'ff'::bit(16)::integer
The following bug has been logged online:
Bug reference: 3765
Logged by: Cade Cairns
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.10
Operating system: Mac OS X 10.5.1
Description:strange results for bit string hex notation cast to bit
Details:
When casti
"Eugene M. Hutorny" <[EMAIL PROTECTED]> writes:
> I noticed strange behaviour of update statements issued to a view with an
> 'on update' rule when the where criterion contains the field being updated.
This isn't a bug --- once the first update is performed, the visible
view contents change and so
Am Dienstag, 20. November 2007 schrieb Eugene M. Hutorny:
> Description:Update count returns zero for a view with 'on update'
> rules when criteria contains updatable field
This is known and documented.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---
"Hussain Jawad-FXRM43" <[EMAIL PROTECTED]> writes:
> 2)There are several postgresql process running after a failed
> restart.Below are the proccesess
> ps -ef|grep post
> root 730 30758 0 12:22 pts/200:00:00 grep post
> postgres 2700 15927 73 12:00 ?00:16:15 postgres: cscti c
The following bug has been logged online:
Bug reference: 3764
Logged by: Eugene M. Hutorny
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Windows 2000
Description:Update count returns zero for a view with 'on update'
rules when criteria c
"Cstdenis" <[EMAIL PROTECTED]> writes:
> When I do a dump and restore of my database my serials change.
This appears to be the same bug reported and fixed about two weeks ago.
http://archives.postgresql.org/pgsql-committers/2007-10/msg00447.php
http://archives.postgresql.org/pgsql-committers/2007
Just forwarding this info along as Zdenek requested...
Turns out this problem is not a bug in pg8.3, it was a problem with our
custom data type. I have since dropped the custom data type and am now
using standard pg float4 arrays. Did the dump and restore, and our app
works just fine, no crash w
Dnia Wt Listopada 20 2007, 15:02, Zdenek Kotala napisał(a):
> [EMAIL PROTECTED] wrote:
>> Dnia Wt Listopada 20 2007, 14:20, Simon Riggs napisał(a):
>>> On Tue, 2007-11-20 at 11:46 +, Heikki Linnakangas wrote:
>> In logs after this:
>> Nov 20 11:02:04 www postgres[32757]: [4-1] wolni>NO
[EMAIL PROTECTED] wrote:
Dnia Wt Listopada 20 2007, 12:46, Heikki Linnakangas napisał(a):
Simon Riggs wrote:
On Tue, 2007-11-20 at 10:12 +, migo wrote:
=> CREATE TABLE phpbb_acl_roles_data ( role_id INT4 DEFAULT '0' NOT NULL
CHECK (role_id >= 0), auth_option_id INT4 DEFAULT '0' NOT NULL C
[EMAIL PROTECTED] wrote:
Dnia Wt Listopada 20 2007, 14:20, Simon Riggs napisał(a):
On Tue, 2007-11-20 at 11:46 +, Heikki Linnakangas wrote:
In logs after this:
Nov 20 11:02:04 www postgres[32757]: [4-1] wolni>NOTICE: CREATE
TABLE /
PRIMARY KEY will create implicit index "phpbb_acl_roles_
Dnia Wt Listopada 20 2007, 14:20, Simon Riggs napisał(a):
> On Tue, 2007-11-20 at 11:46 +, Heikki Linnakangas wrote:
>> >> In logs after this:
>> >> Nov 20 11:02:04 www postgres[32757]: [4-1] wolni>NOTICE: CREATE
>> TABLE /
>> >> PRIMARY KEY will create implicit index "phpbb_acl_roles_data_pk
On Tue, 2007-11-20 at 11:46 +, Heikki Linnakangas wrote:
> >> In logs after this:
> >> Nov 20 11:02:04 www postgres[32757]: [4-1] wolni>NOTICE: CREATE TABLE /
> >> PRIMARY KEY will create implicit index "phpbb_acl_roles_data_pkey" for
> >> table
> >> Nov 20 11:02:04 www postgres[32731]: [2-1]
Dnia Wt Listopada 20 2007, 12:46, Heikki Linnakangas napisał(a):
> Simon Riggs wrote:
>> On Tue, 2007-11-20 at 10:12 +, migo wrote:
>>> => CREATE TABLE phpbb_acl_roles_data ( role_id INT4 DEFAULT '0' NOT NULL
>>> CHECK (role_id >= 0), auth_option_id INT4 DEFAULT '0' NOT NULL CHECK
(auth_option
Dnia Wt Listopada 20 2007, 12:12, Simon Riggs napisał(a):
> On Tue, 2007-11-20 at 10:12 +, migo wrote:
>> The following bug has been logged online:
>>
>> Bug reference: 3763
>> Logged by: migo
>> Email address: [EMAIL PROTECTED]
>> PostgreSQL version: 8.2.4
>> Operating syst
Simon Riggs wrote:
On Tue, 2007-11-20 at 10:12 +, migo wrote:
=> CREATE TABLE phpbb_acl_roles_data ( role_id INT4 DEFAULT '0' NOT NULL
CHECK (role_id >= 0), auth_option_id INT4 DEFAULT '0' NOT NULL CHECK
(auth_option_id >= 0), auth_setting INT2 DEFAULT '0' NOT NULL, PRIMARY KEY
(role_id, au
On Tue, 2007-11-20 at 10:12 +, migo wrote:
> The following bug has been logged online:
>
> Bug reference: 3763
> Logged by: migo
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.4
> Operating system: Gentoo
> Description:crash after create table with pr
The following bug has been logged online:
Bug reference: 3763
Logged by: migo
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Gentoo
Description:crash after create table with primary key defined
Details:
On psql console:
=> CREATE TABL
The following bug has been logged online:
Bug reference: 3762
Logged by: Cstdenis
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5/8.3beta2
Operating system: FreeBSD 6.1
Description:Inherited serials change on dump/restore
Details:
Setup
--
Source: Ser
On Mon, 2007-11-19 at 18:38 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Reason to do this now: Perf Tips have been changed for 8.3 to recommend
> > using --single-transaction when restoring pg_dumps, because of fast COPY
> > enhancement. Allowing this to cause an error will
34 matches
Mail list logo
