Euler Taveira de Oliveira escribió:
> Robert Haas escreveu:
> > I'm not real familiar with ts_parse(), but I'm thinking that it
> > doesn't have any special casing for email addresses and is just
> > intended to parse text for full-text-search - in which case splitting
> > on _ is a pretty good alg
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Um ... locale *is* fixed within a given database, or at least
> Tom> LC_COLLATE and LC_CTYPE are. If you see cases where we have
> Tom> this wrong, they may need to be revisited.
> The value of LC_CTYPE etc. is fixed, but the meaning t
> "Tom" == Tom Lane writes:
Tom> The conversion itself is dependent on changeable catalog
Tom> entries, ie, pg_conversion. So "stable" seems the appropriate
Tom> marking to me.
>> That sounds like a bit of a stretch to me... we treat lots of
>> stuff as immutable which is actually easi
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The conversion itself is dependent on changeable catalog
> Tom> entries, ie, pg_conversion. So "stable" seems the appropriate
> Tom> marking to me.
> That sounds like a bit of a stretch to me... we treat lots of stuff as
> immutable wh
> "Tom" == Tom Lane writes:
>> convert_to is a builtin function. If there's a bug here, it's that
>> convert_to is defined as stable rather than immutable. (Sure it
>> depends on server_encoding, but that can't exactly change... if
>> there's any other reason why it's not immutable, I can
I agree that it isn't easy to determine if given text is a valid email
address. As I couldn't use ts_parse, I ended up using a regex, which
worked substantially better at pulling out the emails from the text
stream. I haven't looked at the code, but perhaps it is possible to
do the same thing her
Greetings,
-1 appears to be ignored when '-f -' is set.
test_file contains:
set client_min_messages=error;
create schema tiger_us;
These produce different results:
BEGIN, but no COMMIT:
beren:/data3/tiger> psql -o /dev/null -e \
--no-psqlrc \
Robert Haas escreveu:
> I'm not real familiar with ts_parse(), but I'm thinking that it
> doesn't have any special casing for email addresses and is just
> intended to parse text for full-text-search - in which case splitting
> on _ is a pretty good algorithm.
>
It is a bug. The tsearch claims to
Robert Haas writes:
> On Sat, Sep 5, 2009 at 5:42 AM, Kamil Roman
> wrote:
>> Description: Â Â Â Â 'i' flag i in regexp_replace ignored for polish
>> letters
> I haven't seen a response to this. Anyone think this might be a bug?
If he's using a multibyte character set (UTF8 most likely)
Thanks for having a look at this bug.
According to section 12.8.2 of the postgres manual, ts_parse is
supposed to recognize different types of data, one of which (#4) is an
email address.
The list of recognized data formats for parse can be selected via this query:
SELECT * FROM ts_token_type('
On Thu, Oct 22, 2009 at 10:47 AM, flamin dragon wrote:
>
>
> 2009/10/22 Robert Haas
>>
>> On Wed, Oct 21, 2009 at 12:51 PM, wrote:
>> >
>> > The following bug has been logged online:
>> >
>> > Bug reference: 5130
>> > Logged by:
>> > Email address: flamindrag...@gmail.com
>> > Postgre
On Sat, Sep 5, 2009 at 5:42 AM, Kamil Roman wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5039
> Logged by: Kamil Roman
> Email address: kamil.lech.ro...@gmail.com
> PostgreSQL version: 8.3.7
> Operating system: Windows XP
> Description: 'i' fl
On Fri, Aug 28, 2009 at 9:59 AM, Dan O'Hara wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5021
> Logged by: Dan O'Hara
> Email address: danarasoftw...@gmail.com
> PostgreSQL version: 8.3.7
> Operating system: win32
> Description: ts_parse doesn
2009/9/29 Yaming Gu :
> Hi, Robert,
>
> According to your recommendations, I tried to load plperu, almost the same
> error messages have shown:
>
> D:\Program Files\Postgresql\8.3\bin>createlang -U postgres plperlu example
>
> Password:
>
> createlang: language installation failed: server closed t
Andrew Gierth writes:
> Peter> You haven't told us how the convert_to function is defined.
> convert_to is a builtin function. If there's a bug here, it's that
> convert_to is defined as stable rather than immutable. (Sure it depends
> on server_encoding, but that can't exactly change... if ther
2009/10/22 Robert Haas
> On Wed, Oct 21, 2009 at 12:51 PM, wrote:
> >
> > The following bug has been logged online:
> >
> > Bug reference: 5130
> > Logged by:
> > Email address: flamindrag...@gmail.com
> > PostgreSQL version: any
> > Operating system: Win XP Pro SP2
> > Description:
"Savita" writes:
> I would like to know if there is anyway we can get the same sorting order
> irreespective of lc_collate value when doing the select query.
You could do "ORDER BY col USING ~<~", but on the whole it's really
better to set LC_COLLATE the way you want.
reg
"Savita" writes:
> could not determine encoding for locale "Ja_JP": codeset is "IBM-943"
Hmph. Do you know which of Postgres' character set encodings that
corresponds to? If there is one, fixing this is just a matter of
adding an entry to the table in src/port/chklocale.c.
Some googling sugges
"Geok Hua Yap" writes:
> select timeofday()::timestamp;
> ERROR: invalid input syntax for type timestamp: "Thu Oct 22 15:16:25.113963
> 2009 SGT"
SGT was added to the default set of timezone abbreviations as of 8.4.
If you want to use Singapore timezone in 8.3, you'll probably want to
add it to
On Thu, Oct 22, 2009 at 3:23 AM, Geok Hua Yap wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5132
> Logged by: Geok Hua Yap
> Email address: geokhua8...@yahoo.com.sg
> PostgreSQL version: 8.3.1
> Operating system: CentOS 5.2
> Description: Inval
"aihongwei" writes:
> In x86_64 platform,
> I input command "ulimit -s 2048" to limit the stack size.Then I startup the
> server,and when i do some recursion operation, the pgsql will lost in some
> time.
> It seems that The stack_max_depth does work.
If you read the description of that setting,
The following bug has been logged online:
Bug reference: 5135
Logged by: Savita
Email address: savita.ha...@gmail.com
PostgreSQL version: 8.3.5
Operating system: AIX
Description:sorting order
Details:
Hi
I have 8.3.5 installed. The sorting order in potsgres would b
The following bug has been logged online:
Bug reference: 5134
Logged by: Savita
Email address: savita.ha...@gmail.com
PostgreSQL version: 8.3.5
Operating system: AIX HP
Description:initdb fails with return code 1
Details:
Hi
We have written the script to create th
The following bug has been logged online:
Bug reference: 5132
Logged by: Geok Hua Yap
Email address: geokhua8...@yahoo.com.sg
PostgreSQL version: 8.3.1
Operating system: CentOS 5.2
Description:Invalid Function
Details:
select timeofday()::timestamp;
ERROR: invalid
On Wed, Oct 21, 2009 at 12:51 PM, wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5130
> Logged by:
> Email address: flamindrag...@gmail.com
> PostgreSQL version: any
> Operating system: Win XP Pro SP2
> Description: Failed to run initdb:1
> Details:
>
>
On Wed, Oct 21, 2009 at 11:23 PM, aihongwei wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5131
> Logged by: aihongwei
> Email address: ufo008...@163.com
> PostgreSQL version: 8.0.0
> Operating system: linux x86_64
> Description: The pgsql will
> "Peter" == Peter Eisentraut writes:
>> I have table with bytea column, which is indexed (1)
>> I want to use index during pattern matching (eg. dir like
>> someDirectoryName
>> || '/%'), but concatenation of two strings cause error (2)
>> So I have to use function convert_to (convertin
27 matches
Mail list logo
