On Sun, Dec 14, 2003 at 22:17:35 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
If the sort used to select the records sorts on both the distinct
expressions and the order by expressions you will get a sensible
deterministic result.
Sensible in what
On Mon, Dec 15, 2003 at 06:14:59 -0600,
Bruno Wolff III [EMAIL PROTECTED] wrote:
Doing things as above is pretty much the same as normal distinct on
for purposes of which rows get selected. Of the possible rows that
might get returned for a specific set of values from the distinct on
Bruno Wolff III [EMAIL PROTECTED] writes:
Specifically the interpretation I think makes sense is that
SELECT DISTINCT ON (a, b, c) * FROM tablename ORDER BY d, e, f
should be treated as equvialent to
SELECT * FROM
(SELECT DISTINCT ON (a, b, c) FROM tablename ORDER BY a, b, c, d, e, f) AS t
Bruce Momjian wrote:
Andrew Dunstan wrote:
Now for the fun
part (signals).
Actually, no. I thought fork/exec would be a real mess (as did Tom),
but Claudio has done an excellent job of producing a minimal patch. The
work isn't done yet, but this small patch has taken us much closer, so
Hi,
A year ago Nicolai Tufar [EMAIL PROTECTED] submitted a patch to
change lower-case conversion of identifiers from locale-dependent to
ASCII in this thread:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg01159.php
Tom Lane argued that SQL99 standard states that identifier case
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Now for the fun
part (signals).
Actually, no. I thought fork/exec would be a real mess (as did Tom),
but Claudio has done an excellent job of producing a minimal patch. The
work isn't done yet, but this
Devrim GUNDUZ [EMAIL PROTECTED] writes:
Now, PostgreSQL 7.4 initdb fails if run with locale set to tr_TR:
Ugh :-(
As you can see I in VOID gets converted to i-dotless in conformance
to tr_TR Locale conversion rules, which is not an expected behaviour for
Turkish users who set their locale to
After upgrading to v 7.3.4 I noticed this error message in the database
setup log:
grep: can't open data_path/conversion_create.sql
Turned out initdb is looking for conversion_create.sql.
We're not building this script and I may need to look into the build
process,
but for now can someone tell
Bruce Momjian wrote:
Have you looked at the CONNX signal code on the Win32 page:
http://momjian.postgresql.org/main/writings/pgsql/win32.html
It uses shared memory and events.
Yes, and I just did again. I guess I must be missing something, though -
I don't see what in that code causes the
Although Bruce already stamped the REL7_4_STABLE CVS branch as 7.4.1,
we're not quite ready to wrap the release; I still see three or four
things I think are must fix before releasing. We'll try to push out
7.4.1 on Wednesday or Friday depending on how things go.
The stuff on my radar screen is:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Have you looked at the CONNX signal code on the Win32 page:
http://momjian.postgresql.org/main/writings/pgsql/win32.html
It uses shared memory and events.
Yes, and I just did again. I guess I must be missing something, though -
I said:
[EMAIL PROTECTED] (Edwin S. Ramirez) writes:
[ select count('x') from some_table fails ]
The most direct fix is probably to make any_in() return some random
value (may as well be ((Datum) 0)) instead of producing an error.
After further investigation I have decided that this is
I added this comment to the code in case we don't fix cp -r:
/* We might need to use cp -R one day for portability */
---
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
IIRC we don't copy anything but
Michael Brusser [EMAIL PROTECTED] writes:
Turned out initdb is looking for conversion_create.sql.
We're not building this script and I may need to look into the build
process,
but for now can someone tell me what it does and why we'd need it.
Well, if you don't have it then there won't be any
I have updated the release notes for 7.4.1 and HISTORY as of Dec 14. I
will make further adjustments before the 7.4.1 release.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Sailesh Krishnamurthy wrote:
Hackers
Where are we going on the pgsql/include file conflicts? sqltypes.h is
very common on Win32, and decimal.h might be a problem too. We even
have compatlib.h.
We can tell them to adjust the include path, but what do we do about
win32 system includes that want the system sqltypes.h?
Hi, it seems there is an inconsistency with time zone handling to me:
test=# select version();
version
-
PostgreSQL 7.4 on i686-pc-linux-gnu, compiled by GCC 2.95.3
(1 row)
test=#
I notice this in 7.3.4:
test=# create table test (a int4, b int4);
CREATE TABLE
test=# create index idx on test(a) where b is null;
CREATE INDEX
test=# \d test
Table public.test
Column | Type | Modifiers
+-+---
a | integer |
b | integer |
Indexes: idx
Tatsuo Ishii [EMAIL PROTECTED] writes:
Hi, it seems there is an inconsistency with time zone handling to me:
Yeah, the set of time zone names accepted by SET TIME ZONE doesn't have
a whole lot to do with the set of time zone names you can specify as
part of a timestamptz input string.
This is
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I cannot think of any commit that fixed that??? Is it fixed in 7.3.5?
7.3.5 exhibits the same misbehavior. The bug is actually that the index
doesn't get dropped when you drop the column, and it was fixed here:
2003-05-28 12:03 tgl
21 matches
Mail list logo
