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
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
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
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=# se
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?
--
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
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 b
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
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 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 Rob
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Mon, 15 Dec 2003, Tom Lane wrote:
> > 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 tr_TR.
>
> W
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 so
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
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
After upgrading to v 7.3.4 I noticed this error message in the database
setup log:
grep: can't open /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 me what it
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
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
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
conv
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
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)
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
>
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.
>
> Sensi
22 matches
Mail list logo