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',
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 parameter
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
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 possible
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 will
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;
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,
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. From a
* 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 fields. It'd
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 sure the date
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:
*
* 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, but
* 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 ''
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
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
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 triggers.
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 using 1 8K
--- 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/
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
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
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
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.
-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 the tree
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 initdb, and
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?
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
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
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
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
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
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
^^^
31 matches
Mail list logo
