The following bug has been logged online:
Bug reference: 4166
Logged by: Mike Gagnon
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1-1
Operating system: Windows XP
Description:Alter table add column from PgAdminIII
Details:
Hi Postgres Experts,
I used PGA
Mike Gagnon wrote:
I used PGAdmin III to add a character varying column(400) length, not null
default ''. I get the column displayed in psql when I do a simple query
like SELECT * from MyTable limit 1;
When I try to do Update MyTable set NewColumn='something'; I get the error
saying that the
"Mike Gagnon" <[EMAIL PROTECTED]> writes:
> I used PGAdmin III to add a character varying column(400) length, not null
> default ''. I get the column displayed in psql when I do a simple query
> like SELECT * from MyTable limit 1;
> When I try to do Update MyTable set NewColumn='something'; I g
I've found some strange behavoiur of TOAST'able tables.
1. Lets create table with toastable column
CREATE table toastable (
x int ,
y text
);
2. Check toast size - as the table is empty it's size 0 - OK
SELECT relname, pg_relation_size(oid) FROM pg_class where oid=(select
reltoastrelid from
The following bug has been logged online:
Bug reference: 4167
Logged by: nicoanto
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1.0
Operating system: Windows
Description:When generating UUID using UUID-OSSP module, UUIDs are
not unique on Windows
Details:
=?iso-8859-2?Q?Wojciech_Strza=B3ka?= <[EMAIL PROTECTED]> writes:
> In my opinion the fact that dropping column doesn't release it's toastable
> resources is a bug.
To make that happen would require (at least) a full table scan. I think
most people are more interested in DROP COLUMN being a cheap
> To make that happen would require (at least) a full table scan. I think
> most people are more interested in DROP COLUMN being a cheap operation
> than in having the space be reclaimed quickly.
> For a comparison point: large field values that don't happen to get
> toasted don't vanish immedia
Am Mittwoch, 14. Mai 2008 schrieb nicoanto:
> I am using the 8.3.1 version of PostgreSQL. I wrote a simple function on
> order to generate UUID values using the UUID-OSSP module
> The code of the function is the following one :
>
> CREATE FUNCTION uuidgen() RETURNS CHAR(36) AS $$
> BEGIN
Peter Eisentraut wrote:
> Am Mittwoch, 14. Mai 2008 schrieb nicoanto:
> > I am using the 8.3.1 version of PostgreSQL. I wrote a simple function on
> > order to generate UUID values using the UUID-OSSP module
> > The code of the function is the following one :
> >
> > CREATE FUNCTION uuidgen() R
Peter Eisentraut wrote:
Am Mittwoch, 14. Mai 2008 schrieb nicoanto:
I am using the 8.3.1 version of PostgreSQL. I wrote a simple function on
order to generate UUID values using the UUID-OSSP module
The code of the function is the following one :
CREATE FUNCTION uuidgen() RETURNS CHAR(36) AS
Am Mittwoch, 14. Mai 2008 schrieb Alvaro Herrera:
> Hmm, surely the problem is unrelated? He gets the same numbers on
> _Windows_, whereas Ubuntu shows the good behavior.
Oh, I read it backwards. So then the random number generator on Windows is
the problem in this case.
> Also, OOSP-UUID does
Peter Eisentraut wrote:
> Am Mittwoch, 14. Mai 2008 schrieb Alvaro Herrera:
> > Hmm, surely the problem is unrelated? He gets the same numbers on
> > _Windows_, whereas Ubuntu shows the good behavior.
>
> Oh, I read it backwards. So then the random number generator on Windows is
> the problem i
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 14. Mai 2008 schrieb Alvaro Herrera:
>> Hmm, surely the problem is unrelated? He gets the same numbers on
>> _Windows_, whereas Ubuntu shows the good behavior.
> Oh, I read it backwards. So then the random number generator on Windows is
=?iso-8859-2?Q?Wojciech_Strza=B3ka?= <[EMAIL PROTECTED]> writes:
>> To make that happen would require (at least) a full table scan. I think
>> most people are more interested in DROP COLUMN being a cheap operation
>> than in having the space be reclaimed quickly.
>> For a comparison point: large
The following bug has been logged online:
Bug reference: 4168
Logged by: Francisco Leovey
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: SuSE Linux 9.2
Description:ECPG refuses datestyle SQL
Details:
if you write
EXEC SQL SET datestyle
15 matches
Mail list logo
