Peter Eisentraut wrote:
Christopher Kings-Lynne writes:
I'm just interested in what everyone's personal plans for 7.5
development are?
There are still some low-hanging fruit and some
below-the-cloudy-sky-hanging fruit in there, for instance
[...snip...]
Basic array support
^^^
I
After installing 7.4 I created database completely from scratch
with cyrillic locale:
su postgres
export LC_CTYPE=ru_RU.KOI8-R
export LC_COLLATE=ru_RU.KOI8-R
/usr/local/pgsql/bin/initdb -D /db2/pgdata
You need to go:
/usr/local/pgsql/bin/initdb -D /db2/pgdata -E KOI8
To set the default encoding t
Le Jeudi 27 Novembre 2003 20:56, E.Rodichev a écrit :
> After installing 7.4 I created database completely from scratch
> with cyrillic locale:
Dear Evgeny,
If you want to go 'fast', do not hesitate to install pgAdmin3 GUI from
http://www.pgadmin.org. We will be able to create and manage a databa
ow wrote:
--- Tom Lane <[EMAIL PROTECTED]> wrote:
People might be more interested in debating this topic with you if we
hadn't discussed it at length just a couple months back. There wasn't
consensus then that we had to offer an escape hatch, and you've not
offered any argument that wasn't made b
E.Rodichev writes:
> I just noticed some incorrect behaviour for postgresql-7.4 related
> to locale.
Maybe you should first read the documentation to understand how it
actually works.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)
Hi,
I just noticed some incorrect behaviour for postgresql-7.4 related
to locale.
After installing 7.4 I created database completely from scratch
with cyrillic locale:
su postgres
export LC_CTYPE=ru_RU.KOI8-R
export LC_COLLATE=ru_RU.KOI8-R
/usr/local/pgsql/bin/initdb -D /db2/pgdata
/usr/local/pg
Neil Conway writes:
> Building PostgreSQL outside the source tree is slightly broken:
I've installed a patch that should fix this.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Thu, Nov 27, 2003 at 06:30:54PM +0100, Peter Eisentraut wrote:
> Alvaro Herrera writes:
>
> > (I will probably be doing lots of translation work too, or maybe enable
> > someone else to do it ...)
>
> I think in 7.5 we'll be able to get everything fully translat{ed|able}.
> We already have ini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 27 November 2003 1:12 am, Peter Eisentraut wrote:
> Jonathan Gardner writes:
> > I know this sounds kind of silly, but I think I would like to be able
> > to send a query to PostgreSQL, and have it parse it into a tree, and
> > then pass th
Alvaro Herrera writes:
> (I will probably be doing lots of translation work too, or maybe enable
> someone else to do it ...)
I think in 7.5 we'll be able to get everything fully translat{ed|able}.
We already have initdb, and we'll do ecpg, pg_ctl, and decide the fate of
initlocation and ipcclean
Christopher Kings-Lynne writes:
> I'm just interested in what everyone's personal plans for 7.5
> development are?
Here is a pretty good hit list:
http://developer.postgresql.org/docs/postgres/unsupported-features-sql99.html
There are still some low-hanging fruit and some
below-the-cloudy-sky-h
ow wrote:
I'd like to emphasize again that NOT having an index on the FK column is a
perfectly valid approach, despite some opinions to the contrary.
OW, you might insist that there are several cases when an index is not
needed, but I didn't propose to create the index automatically (this
real
Kevin Brown wrote:
WAL is not the bottleneck ... as I already mentioned today, pg_clog (and
more specifically the meaning of transaction IDs) is what really makes a
cluster an indivisible whole at the physical level.
The ability to restore a single large database quickly is, I think,
a reasonabl
--- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> In what scenarios? I'd easily buy this if you are talking about small
> tables.
>
Read the message again.
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> And that helps how? The problem is to detect whether there are any
>> children left from the old postmaster, when what you have to work from
>> is the pid-file it left behind.
> fine. We need shared memory for that. How about us
On Wed, Nov 26, 2003 at 10:11:20PM -0800, ow wrote:
> --- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > On Thu, Nov 27, 2003 at 12:40:28AM +0100, Andreas Pflug wrote:
> >
> > > A common mistake, can't count how often I created this one... And not
> > > easy to find, because EXPLAIN won't explain
Hi there,
new version of tsearch2 is available for testing from
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2
* tsearch-v2-7.3.tar.gz - full archive for 7.3.X releases
* tsearch-v2-7.4.patch.gz - patch for 7.4 release
Changes:
* Implement support of compound words in ispell diction
Stephen,
You can do whatever you can do with an insert now, so yes, I think that
is possible. Even if the current patch doesn't do that, it would
certainly be a start.
Dave
On Thu, 2003-11-27 at 10:21, Stephen Frost wrote:
> * Dave Cramer ([EMAIL PROTECTED]) wrote:
> > There is a patch floating
* Dave Cramer ([EMAIL PROTECTED]) wrote:
> There is a patch floating around for informix load/unload
>
> the syntax is load from 'file' insert into , and unload to 'file'
> select "whatever you like"
>
> Would this solve the problem?
I'm not sure. It depends on what you can do with the '...
* Rod Taylor ([EMAIL PROTECTED]) wrote:
> How about COPY into a TEMP TABLE for 10k lines, then do an
> insert into real_table select from temp_table;
> which converts the data?
>
> You could of course thread the load so 2 or 3 processes execute the data
> import.
Sure, this would work,
There is a patch floating around for informix load/unload
the syntax is load from 'file' insert into , and unload to 'file'
select "whatever you like"
Would this solve the problem?
Dave
On Thu, 2003-11-27 at 09:38, Rod Taylor wrote:
> On Thu, 2003-11-27 at 09:28, Stephen Frost wrote:
> > *
On Thu, 2003-11-27 at 09:28, Stephen Frost wrote:
> * Bruno Wolff III ([EMAIL PROTECTED]) wrote:
> > On Thu, Nov 27, 2003 at 09:15:20 -0500,
> > Stephen Frost <[EMAIL PROTECTED]> wrote:
> > > I don't believe it's possible, currently, to correctly import this
> > > data with copy. I'm not sur
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
> On Thu, Nov 27, 2003 at 09:15:20 -0500,
> Stephen Frost <[EMAIL PROTECTED]> wrote:
> > I don't believe it's possible, currently, to correctly import this
> > data with copy. I'm not sure the date fields would even be accepted
> > as date field
On Thu, Nov 27, 2003 at 09:15:20 -0500,
Stephen Frost <[EMAIL PROTECTED]> wrote:
>
> I don't believe it's possible, currently, to correctly import this
> data with copy. I'm not sure the date fields would even be accepted
> as date fields. It'd be nice if this could be made to work. Fro
Hi,
Consider the following input data:
1234,24.50,10-Jan-2003,10/1/03,10-01-2003,hiall
The interpretation for the numbers is:
1234 = 12.34, 24.50 = 24.50
The interpretation for the dates is:
January 10th, 2003, October 1st, 2003, October 1st, 2003
I don't believe it's possible, cur
Hello!
Explain analyze takes 3 times more time for execution. Why?
wow=# \timing
Timing is on.
wow=# select max(click.accesses) from click;
max
--
10944762
(1 row)
Time: 105,654 ms
wow=# explain analyze select max(click.accesses) from click;
On Thu, 2003-11-27 at 00:50, Marc G. Fournier wrote:
> Based on discussions on -hackers, and baring any objections betwen now and
> then, I'm going to go through all files in CVS and change:
>
> $Id$ -> $PostgreSQL$
>
> I will do this the evening of Friday, November 29th ...
I presume you
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 1. You can't easily generate a clean diff of your local version against
>> the original imported from postgresql.org. The changes you actually
>> made get buried in a mass of useless $Foo$ diff lines. Stripping those
>> out is
On Thu, Nov 27, 2003 at 09:49:22AM +0100, Nhan NGO DINH wrote:
> Hi,
>
> This is really not a problem, may be in other circumstances...
> This output has been obtained from a PostgreSQL 7.3.4
>
> ===
> testdb=# select to_timestamp('23:20:30.123456', 'HH24:MI:SS.US')::time;
> to_timestamp
>
Jonathan Gardner writes:
> I know this sounds kind of silly, but I think I would like to be able to
> send a query to PostgreSQL, and have it parse it into a tree, and then pass
> the tree back to me somehow. Of course, I don't want the query to actually
> execute.
There is a configuration parame
Hi,
This is really not a problem, may be in other circumstances...
This output has been obtained from a PostgreSQL 7.3.4
===
testdb=# select to_timestamp('23:20:30.123456', 'HH24:MI:SS.US')::time;
to_timestamp
-
23:20:30.123459
(1 row)
testdb=# select to_timestamp('23:20:30', 'H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I know this sounds kind of silly, but I think I would like to be able to
send a query to PostgreSQL, and have it parse it into a tree, and then pass
the tree back to me somehow. Of course, I don't want the query to actually
execute.
Writing the fro
32 matches
Mail list logo
