Is this a documented phenomenon with the "convert" function? The first
result is what's expected:
SELECT convert('Gregoire' USING utf8_to_iso_8859_15);
"Gregoire"
But I don't understand the next result, when I put an acute accent over the
first "e":
SELECT convert('Grégoire' USING utf8_to_iso_
On Sun, Jan 28, 2007 at 07:27:12PM -0700, Michael Fuhr wrote:
> I wonder if the OP is doing something like this:
[...]
> test=> INSERT INTO test VALUES (E'\202\232'); -- \202=0x82, \232=0x9a
Another possibility, perhaps more likely, is that some connection
didn't set client_encoding to win1250 bef
Paul Lambert wrote:
> Im in the process of finalising my conversion from M$ SQL server to
> Postgres - all of which I'm very happy about so far.
>
> The database I work with has 37 tables, 5 of which run into the order of
> tens of millions of records and approximately another 10 can run into
> mi
I made a some future investigation. I find and identified an exact line in
databse. Exact column that cause a problem, I am able to select column into
testtable while in "testtable" it retain its bad behavior. fortunally,
this row does not contain vital
data so I can drop it rather without a
Paul Lambert <[EMAIL PROTECTED]> writes:
> I.e. can I create a data file on D drive which holds tables a, b and
> e, and a data file on E drive which holds tables c, d and f.
>
> If this is possible, could someone point me to some documentation so I
> can experiment a little.
Read the doc section
Im in the process of finalising my conversion from M$ SQL server to
Postgres - all of which I'm very happy about so far.
The database I work with has 37 tables, 5 of which run into the order of
tens of millions of records and approximately another 10 can run into
millions depending on the size
On Sun, Jan 28, 2007 at 06:33:16PM -0500, Tom Lane wrote:
> "NTPT" <[EMAIL PROTECTED]> writes:
> > May be a bug in charset translation routines of postgres ?
>
> If you think that, you need to provide us with the exact codes that are
> being mistranslated and what you think they should translate t
Just to pinpoint the meaning of my dismay, let me add one comment to my
previous post.
In the What'sNew document for tsearch2 with 8.2
http://www.sai.msu.su/~megera/wiki/Tsearch2WhatsNew
we read:
Don't forget to initdb cluster with correct utf8-locale !
initdb -D /usr/local/pgsql-dev/data.el_ut
MULE_INTERNAL is used for an intermediate encoding between LATIN2 and
WIN1250. The error message indicates that 0x9a of LATIN2 cannot be
mapped to WIN1250.
You can see 0x00 in the position for 0x9a (between 0x99 and 0x9b) in
the encoding map in
src/backend/utils/mb/conversion_procs/latin2_and_win1
While making POC (proof of concept) for any project, we clearly mention at
the end of the document that loss of data is not going to be our
responsibility and thats how we guys save our ass right in the begening.
What happened with you has happened with us many a times but our bold and
italicized
tom wrote:
> the way that I'm using perl is to do a full prepare and execute
> statements, which as I understand perl, will do all the character
> escaping necessary to store the message. meaning, If I have
> characters like (') or (`) they should be escaped when they are
> entere
On Sun, Jan 28, 2007 at 01:21:09PM -0500, Bill Moran wrote:
> The only thing that's missing is row-level granularity. There's at least
> one project out there supporting that, and you can also simulate it with
> clever usage of stored procedures and the ability to run them with the
> permissions
"NTPT" <[EMAIL PROTECTED]> writes:
> Without "set client_encoding to win1250" query works. I am curious why there
> is a MULE_INTERNAL mentioned even when \l+ say that corresponding database
> is created with (and even all the cluster) LATIN2 encoding.
The conversions between LATIN2 and WIN12
Hi.
I have a strange problem in postgres 8.1.4 (gentoo 64bit on AMD64
platform)
My database is created vith LATIN-2 encoding for correct vieving of
nacional specific characters ( czech language )
inside code of my php application is setting client encoding to win1250
because I need outpu
For what may be really strange reasons I am trying to store emails
into a database table. The idea is to take the entire original
message and store it into a table with two columns, an serial primary
key column and a column for the message.
Originally I thought I would just use column type
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/07 15:18, garry saddington wrote:
> On Sun, 2007-01-28 at 09:57 -0600, Ron Johnson wrote:
>> On 01/28/07 07:05, garry saddington wrote:
[snip]
>> When you say "certain days", you mean "days of the week"?
>>
>> If so, create a view like:
>> CRE
On 1/26/07, BluDes <[EMAIL PROTECTED]> wrote:
Hi everyone,
I have a problem with one of my costomers.
I made a program that uses a PostgreSQL (win32) database to save its data.
My customer claims that he lost lots of data reguarding his own clients
and that those data had surely been saved on t
"Phil Endecott" <[EMAIL PROTECTED]> writes:
> If I understand it correctly, it is still doing a sequential scan on
> part_tsearch that does not terminate early due to the limit clause. So
> I'm still seeing run times that are rather worse than I think should be
> possible. Can it not step thro
On Sun, 2007-01-28 at 09:57 -0600, Ron Johnson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/28/07 07:05, garry saddington wrote:
> > I have a table definition such as:
> >
> > CREATE TABLE attendance
> > (
> > attendanceid serial primary key,
> > entered date DEFAULT cur
Thanks for the quick reply Tom.
Tom Lane wrote:
>"Phil Endecott"
>writes:
>> I was not patient enough to wait for the remaining explain-analyse results,
>> but I feel that there is a linear slowdown of about 60x between the raw
>> query and the explain-analyse version.
>
> Slow gettimeofday() .
OK, let me think. In my situation, I'm writing an accounting app. A
typical situation would be a standard user would be able to update data
in a timesheet while an administrator would be able to approve the time
sheet. If I gave the standard user access to the timesheet header
table, they wo
> --- Original Message ---
> From: Peter Eisentraut <[EMAIL PROTECTED]>
> To: pgsql-general@postgresql.org
> Sent: 28/01/07, 17:39:00
> Subject: Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
>
> Dave Page wrote:
> > Also, three just seems like a sensible number to mai
I never said I don't want my trigger to do anything.
My subject line only made it pretty clear that I want to fire my trigger
based on
certain conditions.
I know its kind of a silly feature request but you really can't help it
when you are working with stupid advisors :)
thanks for your reponse an
On 1/29/07, Harpreet Dhaliwal <[EMAIL PROTECTED]> wrote:
Hi
I have a table in which i have a field named 'source'
A trigger is written on this table.
I want this trigger to fire only when after Insert this field 'source'
has value = 'from', otherwise trigger should not be fired at all.
Just wond
Furface <[EMAIL PROTECTED]> wrote:
>
> Thanks Tom. You know I thought about this approach a little more. I
> don't think there's a simple answer to this security problem short of
> placing a proxy server application between the clients and the
> database. The problem with giving database role
"Harpreet Dhaliwal" <[EMAIL PROTECTED]> writes:
> I want this trigger to fire only when after Insert this field 'source'
> has value = 'from', otherwise trigger should not be fired at all.
> Just wondering if its really possible?
No, and it seems pretty silly as a feature request. Why don't you j
However, if the primary key is entirely within those six columns, there
will have to be an index on it in both tables to enforce the primary key
constraint. In that case, an inner join could be performed with an index
lookup or an index scan plus hash join, for a query that didn't use any
oth
Hi
I have a table in which i have a field named 'source'
A trigger is written on this table.
I want this trigger to fire only when after Insert this field 'source'
has value = 'from', otherwise trigger should not be fired at all.
Just wondering if its really possible?
Thanks in advance.
Harpreet
"Michael Schmidt" <[EMAIL PROTECTED]> writes:
> ... Regarding how I concluded
> that PGPASSFILE was deprecated for pg_dump, I offer the following.
> 1. The documentation for pg_dump in the manual (Section VI) includes a
> section labeled "Environment". This lists PGDATABASE, PGHOST, PGPORT,
>
Dave Page wrote:
> Also, three just seems like a sensible number to maintain. I kinda
> like Magnus' idea to put older releases into a sort of 'retired' mode
> though, and build only the binaries for PostgreSQL itself.
But would that give people who have previously used the full installer
an upgr
"Joris Dobbelsteen" <[EMAIL PROTECTED]> writes:
> So perhaps What would have been better without surrogate keys
> all-over should have been "My database where I extremely overdid
> it with surrogate keys".
Fair enough. It's generally true that going to extremes with anything
causes problems. :)
>-Original Message-
>From: Douglas McNaught [mailto:[EMAIL PROTECTED]
>Sent: zondag 28 januari 2007 16:29
>To: Joris Dobbelsteen
>Cc: John Meyer; pgsql-general@postgresql.org
>Subject: Re: [GENERAL] counting query
>
>"Joris Dobbelsteen" <[EMAIL PROTECTED]> writes:
>
>> What would have been
Mr. Lane and Mr. Momjian,
Well, I asked and I got an answer. So be it. Regarding how I concluded that
PGPASSFILE was deprecated for pg_dump, I offer the following.
1. The documentation for pg_dump in the manual (Section VI) includes a section
labeled "Environment". This lists PGDATABASE, PGH
"Phil Endecott" <[EMAIL PROTECTED]> writes:
> I was not patient enough to wait for the remaining explain-analyse results,
> but I feel that there is a linear slowdown of about 60x between the raw
> query and the explain-analyse version.
Slow gettimeofday() ... fairly common on desktop-grade PC ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/07 10:43, A. Kretschmer wrote:
> am Sun, dem 28.01.2007, um 10:25:33 -0600 mailte Ron Johnson folgendes:
>> Hi.
>>
>> These fields do not use any disk space, as the data in them is
>> derived on the fly.
>>
>> For example:
>> CREATE TABLE T_E
am Sun, dem 28.01.2007, um 10:25:33 -0600 mailte Ron Johnson folgendes:
> Hi.
>
> These fields do not use any disk space, as the data in them is
> derived on the fly.
>
> For example:
> CREATE TABLE T_EXAMPLE (
> SOME_DATE DATE,
> JDATE COMPUTED BY EXTRACT(JULIAN FROM SOME_DATE)
> );
>
> A
Dear All,
I want to find all of the msg_ids from "messages" that are not in table
"part_tsearch", where both tables are large but the result of the
query is normally small, and often empty. To 'protect' the application
against the unusual case where the result of the query is large I have
adde
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
These fields do not use any disk space, as the data in them is
derived on the fly.
For example:
CREATE TABLE T_EXAMPLE (
SOME_DATE DATE,
JDATE COMPUTED BY EXTRACT(JULIAN FROM SOME_DATE)
);
A work-around is to create a function, and reference
On 1/28/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
This is the great synthetic-vs-natural key debate.
Truly. But what the heck!
Surrogate keys are not evil, and they do have value. I see no value in
proclaiming "surrogate keys are evil, do not use them".
Surrogate keys do have advantages:
Thanks Tom. You know I thought about this approach a little more. I
don't think there's a simple answer to this security problem short of
placing a proxy server application between the clients and the
database. The problem with giving database role accounts to each and
every user is that the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/07 07:05, garry saddington wrote:
> I have a table definition such as:
>
> CREATE TABLE attendance
> (
> attendanceid serial primary key,
> entered date DEFAULT current_date NOT NULL,
> absent boolean,
> authorization text default 'N'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/07 08:36, John Meyer wrote:
> Joris Dobbelsteen wrote:
>>> CREATE TABLE attendance
>>> (
>>> attendanceid serial primary key,
>> Why you have this??? You already have (entered,timeperiod,studentid)
>> that you can use, since that must be uniq
"Joris Dobbelsteen" <[EMAIL PROTECTED]> writes:
> What would have been better without surrogate keys all-over:
> * Easier to write complex queries with much fewer tables to be queried.
> * Much faster query performance, as fewer tables need to be referenced.
> * Better integrity enforcement with s
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of John Meyer
>Sent: zondag 28 januari 2007 15:36
>To: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] counting query
>
>Joris Dobbelsteen wrote:
>>>
>>> CREATE TABLE attendance
>>> (
>>> attendanceid s
Joris Dobbelsteen wrote:
>>
>> CREATE TABLE attendance
>> (
>> attendanceid serial primary key,
>
> Why you have this??? You already have (entered,timeperiod,studentid)
> that you can use, since that must be unique too. Try to avoid surrogate
> keys as much as possible (it really increases perfor
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of garry
>saddington
>Sent: zondag 28 januari 2007 14:06
>To: pgsql-general@postgresql.org
>Subject: [GENERAL] counting query
>
>I have a table definition such as:
>
>CREATE TABLE attendance
>(
> attendance
Michael Schmidt wrote:
Fellow PostgreSQL fans,
1. I don't see that this would pose a major security risk. In
> fact, in applications where the user enters the password for each
> session, the password need never be saved to disk, which seems a
> definite security advantage. Some folks have
Dave Page wrote:
Oisin Glynn wrote:
My 8.2c,
Having 8.1 end of life this soon after the release of 8.2 seems pretty
harsh.
Yeah, I agree. In part I'm basing the idea to support the current and 2
previous branches on the amount of work required to build a complete set
of point releases in
I have a table definition such as:
CREATE TABLE attendance
(
attendanceid serial primary key,
entered date DEFAULT current_date NOT NULL,
absent boolean,
authorization text default 'N',
timeperiod char(2) check(timeperiod in('AM','PM')),
days varchar(10),
studentid int,
unique(ente
Oisin Glynn wrote:
My 8.2c,
Having 8.1 end of life this soon after the release of 8.2 seems pretty
harsh.
Yeah, I agree. In part I'm basing the idea to support the current and 2
previous branches on the amount of work required to build a complete set
of point releases in one go - 3 seems m
Over the past few days, I have been reading everything I could about
tsearch2, but I cannot figure out what the latest status is concerning the
"default locale" on a Windows UTF-8 database under PostgreSQL 8.2.
More specifically, I have a UTF-8 database containing information in five
different Eu
51 matches
Mail list logo
