Thanks. TODO updated.
> Bruce Momjian writes:
>
> > Would people please check the TODO list in pgsql/doc/TODO or on our web
> > site, and let me know if there are any items that need a dash because
> > they are completed in 7.1? I think I may have missed a few.
>
> The following are done:
>
> * Make n of CHAR(n)/VARCHAR(n) the number of letters, not bytes
>
> I think this might be done (Tatsuo, what's the status?)
Not yet. Probably will be left for 7.2.
--
Tatsuo Ishii
> I think some people feel that we ought to raise an error rather than
> silently truncating the input. However, given that we do intend to
> truncate the input, it seems to me that applying CHECK constraints
> post-truncation is the Right Thing. In general a CHECK ought to be
> applied after an
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is this correct behaviour? Perhaps it is, as CHECK is checking the
> truncated value - but I just want to make sure it's not a bug!
I think some people feel that we ought to raise an error rather than
silently truncating the input. However
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Would people please check the TODO list in pgsql/doc/TODO or on our web
> site, and let me know if there are any items that need a dash because
> they are completed in 7.1? I think I may have missed a few.
* have INTERSECT/EXCEPT prevent duplicates un
I just ran across this recent example:
If you perform the following, you get a truncated input:
test=# create table example (type char(5) NOT NULL);
CREATE
test=# insert into example VALUES ('VOLUME');
INSERT 156884 1
test=# select * from example;
type
---
VOLUM
(1 row)
However, if you ad
Don't know whether this belongs on the TODO, but it probably needs to go
somewhere in a 'New Features' section (at least the first two items):
pg_dump:
- Support BLOBs in pg_dump (pjw)
- new utility, pg_restore, which will read dump files and restore
all/some of the dump. Also suppo
"Barnes, Sandy (Sandra)" <[EMAIL PROTECTED]> writes:
>> Any ideas on why this error would occur after dropping an existing
>> database and than re-creating it (createdb)?
I assume what you're really talking about is
Database 'xxx', OID nnn, has disappeared from pg_database
?
It's theoret
> Any ideas on why this error would occur after dropping an existing
> database and than re-creating it (createdb)? The only work around so far
> is to completely destroy the postgres instance and start over.
>
> It appears that the pg_database may be getting currupted.
>
> Sandy Barnes
> Ho
Hannu Krosing writes:
> > ::=
> >
> > | OF
> > [ ]
> > [ ]
> to me it seems that only this is OR-d : | OF
>
>
> and the rest ([ ],[ ])is just
> optional
Nope. In that case it would read
::=
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > ::=
> >
> > | OF
> > [ ]
> > [ ]
>
> to me it seems that only this is OR-d : | OF
>
> and the rest ([ ],[ ])is just
> optional
The grammar is less t
Bruce Momjian writes:
> Would people please check the TODO list in pgsql/doc/TODO or on our web
> site, and let me know if there are any items that need a dash because
> they are completed in 7.1? I think I may have missed a few.
The following are done:
* Prevent initdb from running wrong vers
Tom Lane wrote:
[ . . . ]
> A general-purpose connection-reuse facility on the server end cannot
> eliminate these overheads, whereas it's trivial to avoid them within
> the context of a multi-threaded client.
PHP 4.04 does provide support for AOLServer now (which is multithreaded). I haven't had
Tom Lane wrote:
>
> One thing that bothered me is that my reading of the SQL99 draft
> disallows the UNDER syntax you are using. I read:
>
> ::=
> CREATE [ ] TABLE
>
> [ ON COMMIT ROWS ]
>
> ::=
>
>
14 matches
Mail list logo
