> > A larger question is whether unsigned types really add much to the
> > system vs. the bloat. We already have unsigned int4 as oid. Also,
> > unsigned doubles the space of the type, but if a value doesn't fit in
> > 32k, what are the odds it will fit in 64k. I am not sure unsigned
> > optim
> If general opinion is that unsigned types should not be part of
> postgres, I'll have to look at turning them into a contrib type. Please
> let me know.
Providing them as a contrib/ package will allow you to provide the
*full* complement of cross-type conversion and operator functions
without w
Bruce Momjian wrote:
>
> > Adriaan Joubert <[EMAIL PROTECTED]> writes:
> > > Question is: should I add these functions? Are we looking at too much
> > > bloat, i.e. should I replace the (uint2,uint4) combinations with
> > > (int4,uint2) and (int4,uint4)? Lots of combinations are possible, but I
>
> > >> I assume this is not possible in 7.1?
> > >
> > >Just looked in heapam.c - I can fix it in two hours.
> > >The question is - should we do this now?
> > >Comments?
> >
> > It's a bug; how confident are you of the fix?
95% -:)
> I doubt if it's a bug of SELECT. Well what
> 'concurrent UPDAT
> I have started coding a user/group administration tool that allows you
> to add/modify/delete users and groups. I should have something working
> in a week. I will look similar to my pgmonitor tool.
>
semi related to this, I have always thought that the way postgresql
handles the dele
Mark Knox <[EMAIL PROTECTED]> writes:
> Well, this patch seems to produce attlens of 6 as desired, but it
> causes many (13) of the regression tests to fail. Do you want to see
> the regression.diffs?
>>
>> Please.
> See attached.
Does look pretty broken, but I don't see how my idea would have
Philip Warner wrote:
>
> At 19:14 29/03/01 -0800, Mikheev, Vadim wrote:
> >> >Reported problem is caused by bug (only one tuple version must be
> >> >returned by SELECT) and this is way to fix it.
> >> >
> >>
> >> I assume this is not possible in 7.1?
> >
> >Just looked in heapam.c - I can fix it
> >Reported problem is caused by bug (only one tuple version must be
> >returned by SELECT) and this is way to fix it.
> >
>
> I assume this is not possible in 7.1?
Just looked in heapam.c - I can fix it in two hours.
The question is - should we do this now?
Comments?
Vadim
---
[ Replies set to hackers.]
I have started coding a user/group administration tool that allows you
to add/modify/delete users and groups. I should have something working
in a week. I will look similar to my pgmonitor tool.
--
Bruce Momjian| http://candle.pha.pa.us
Hi Tom,
My guess is that it would be possible to insert a check to see if the
installed Postmaster was started with -i, and then choose between Unix
domain sockets or TCP. BUT, whether trying to explain this in the
installation document to the novice user who is setting up PostgreSQL
for about t
Hi all,
The OpenSSL guys are working on a solution to the conflicting
des_encrypt() function names on Solaris and Unixware.
Whilst this bodes well for future versions, how are we going to work
around conflicts with existing versions?
Regards and best wishes,
Justin Clift
Original Mes
On Tuesday, March, 2001-03-27 at 12:54:02, Bruce Momjian wrote:
> I have just released pgmonitor 0.30. I have added a new 'set debug'
> option that should help with porting. I know some people are testing
> Solaris and this may help.
why don't I see any output? PostgreSQL 7.0.2 on RedHat (the R
I'm at the moment installing Postgresql-7.1RC1 on Solaris 7 and 8 over
UltraSPARC.
What do I have to do to report a regression test?
Where should I look for info on this.
Saludos... :-)
--
El mejor sistema operativo es aquel que te da de comer.
Cuida tu dieta.
-
Dirk Lutzebaeck wrote:
>
>INSERT INTO t1 SELECT a FROM t2 ORDER BY a LIMIT 10;
>
>Is it possible in 7.1?
Yes (I tried it).
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97
On Thu, Mar 29, 2001 at 02:29:38PM +0100, Oliver Elphick wrote:
> Peter Eisentraut wrote:
> >Tom Lane writes:
> >
> >> It seems that in pre-7.0 Postgres, this works:
> >>
> >> create table one(id int default 1, descr text);
> >> create table two(id int default 2, tag text) inherits (on
Just a heads up for anyone that might have something outstanding ... I'm
going to package her early evening (~18:30AST) and announce it to both
pgsql-hackers and pgsql-announce when done ...
Once RC2 goes out, its meant to be a "this is what we'd release if docs
were completely ready to go" ...
* Karel Zak <[EMAIL PROTECTED]> [010329 03:10] wrote:
> On Wed, Mar 28, 2001 at 04:10:52PM -0800, Alfred Perlstein wrote:
> > * Tom Lane <[EMAIL PROTECTED]> [010328 16:07] wrote:
> > > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more p
> Adriaan Joubert <[EMAIL PROTECTED]> writes:
> > Question is: should I add these functions? Are we looking at too much
> > bloat, i.e. should I replace the (uint2,uint4) combinations with
> > (int4,uint2) and (int4,uint4)? Lots of combinations are possible, but I
> > do not have a good feel for t
Adriaan Joubert <[EMAIL PROTECTED]> writes:
> Question is: should I add these functions? Are we looking at too much
> bloat, i.e. should I replace the (uint2,uint4) combinations with
> (int4,uint2) and (int4,uint4)? Lots of combinations are possible, but I
> do not have a good feel for the trade-o
Hi,
I finally seem to have my unsigned int2/int4 types working correctly,
but will wait until 7.1 is out of the door, and test a bit more, before
resubmitting.
A question though:
I've put in functions (as copied from the int2/int4 implementation) that
implement operators for differentl
> Tom Lane writes:
>
> > Mathijs Brands <[EMAIL PROTECTED]> writes:
> > > mathijs297 0.1 0.2 6120 3352 pts/1S 01:59:18 0:00
>/opt/pgsql/bin/./postgres mathijs localhost template1 idle
> >
> > The interesting point about this is that the 7.0.3-on-2.7 installation
> > *is* managing to c
Tom Lane writes:
> Mathijs Brands <[EMAIL PROTECTED]> writes:
> > mathijs297 0.1 0.2 6120 3352 pts/1S 01:59:18 0:00
>/opt/pgsql/bin/./postgres mathijs localhost template1 idle
>
> The interesting point about this is that the 7.0.3-on-2.7 installation
> *is* managing to change its PS d
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
Although the liberty to do anything you want seems appealing at first, I
would think that allowing this is not correct from an OO point of view.
> I don't agree; this is equivalent to redefinition of a feature (=method) in
> a descendant clas
Oliver Elphick writes:
> Peter Eisentraut wrote:
> >Tom Lane writes:
> >
> >> It seems that in pre-7.0 Postgres, this works:
> >>
> >> create table one(id int default 1, descr text);
> >> create table two(id int default 2, tag text) inherits (one);
> >>
> >> with the net effect th
Jeroen Eitjes <[EMAIL PROTECTED]> writes:
> I have found a small but annoying bug. I have created a view. The
> SQL-statement in the view contains a GROUP BY statement. Then I compose a
> SQL-statement using this view and another GROUP BY statement and a COUNT(*)
> statement.
This sort of thing w
INSERT INTO t1 SELECT a FROM t2 ORDER BY a LIMIT 10;
Is it possible in 7.1?
Dirk
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can
Hi there,
I have found a small but annoying bug. I have created a view. The
SQL-statement in the view contains a GROUP BY statement. Then I compose a
SQL-statement using this view and another GROUP BY statement and a COUNT(*)
statement. The count(*) statement doesn't count the amount of grouped
r
Peter Eisentraut wrote:
>Tom Lane writes:
>
>> It seems that in pre-7.0 Postgres, this works:
>>
>> create table one(id int default 1, descr text);
>> create table two(id int default 2, tag text) inherits (one);
>>
>> with the net effect that table "two" has just one "id" column wi
Tom Lane wrote:
>I just had a discussion with a user who doesn't want to update from
>6.4.something to 7.0.* because 7.0 broke a feature he likes, namely
>the ability to change the default value of a column inherited from
>a parent table. It seems that in pre-7.0 Postgres, this works:
>
Bruce Momjian wrote:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms
> > > including UnixWare. The UnixWare code will need /dev/kmem permission to
> > > change it's stuff, so I don't know whether we want to do this or not
On Wed, Mar 28, 2001 at 12:37:15PM +0300, Adriaan Joubert wrote:
> Ooops, patch was the wrong way round. Here is a better one.
Applied. I did add another set of braces for easier understanding though.
:-)
To be able to move ECPGt_long_long up the list we would have to bump the
soname of the shar
On Wed, Mar 28, 2001 at 04:10:52PM -0800, Alfred Perlstein wrote:
> * Tom Lane <[EMAIL PROTECTED]> [010328 16:07] wrote:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms
> > > including UnixWare. The UnixWare code will ne
On Tue, 27 Mar 2001, Tom Lane wrote:
> Alexander Klimov <[EMAIL PROTECTED]> writes:
> > First problem is sys/socket.h. Here it has no guards in it (like
> > #ifdef _SOCKET_H
> > #endif), so it could not be included twice, and I have to remove its
> > unnecesarry inclusions.
>
> Are you sure the
Hi,
I've got the weird behaviour in an ecpg programme that when I issue
EXEC SQL SET AUTOCOMMIT TO ON;
transactions behave as one would expect, i.e. I can use BEGIN
WORK/COMMIT/ROLLBACK, but when I set
EXEC SQL SET AUTOCOMMIT TO OFF;
every statement is wrapped in its own tra
34 matches
Mail list logo
