Re: [HACKERS] why was libpq.so's version number bumped?

[Palle Girgensohn]

Still am. ;-)

--On tisdag, december 31, 2002 10.01.34 +0800 Christopher Kings-Lynne 
<[EMAIL PROTECTED]> wrote:

On Mon, 30 Dec 2002, Christopher Kings-Lynne wrote:

> ps. Why is Postgres 7.3 still in ports/databases/postgresql-devel ??

I forgot one other possible answer: perhaps the port maintainer is taking
a well deserved holiday?


Last time I checked, Palle _was_ the port maintainer :)

Chris





---(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 get through to the mailing list cleanly

Re: [HACKERS] Bug in Dependencies Code in 7.3.x?

[Tom Lane]

Tara Piorkowski <[EMAIL PROTECTED]> writes:
> Regardless, my thinking had been that I was looking at an INT with a 
> DEFAULT set, in which case I think this would be a bonified bug, thus my 
> report.

Right --- but *if you'd declared it that way*, the system would have
reacted in the way you were expecting.  SERIAL sets up dependencies that
prevent you from dropping the sequence as a separate entity, while an
INT column with a handmade DEFAULT expression doesn't.

Ideally, a SERIAL column would completely hide the fact that it's made
from a sequence and a default expression.  We're not there yet ... but
7.3 is closer than ever before.  (It'd be interesting to look at whether
Rod Taylor's DOMAIN work could help button things up.)

regards, tom lane

---(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 get through to the mailing list cleanly

Re: [HACKERS] why was libpq.so's version number bumped?

[Christopher Kings-Lynne]

> On Mon, 30 Dec 2002, Christopher Kings-Lynne wrote:
> 
> > ps. Why is Postgres 7.3 still in ports/databases/postgresql-devel ??
> 
> I forgot one other possible answer: perhaps the port maintainer is taking
> a well deserved holiday?

Last time I checked, Palle _was_ the port maintainer :)

Chris


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Bug in Dependencies Code in 7.3.x?

[Tara Piorkowski]

Tom Lane wrote:

Tara Piorkowski <[EMAIL PROTECTED]> writes:

junk=> create table testing
junk-> (testing_id serial not null primary key);
NOTICE:  CREATE TABLE will create implicit sequence 
'testing_testing_id_seq' for SERIAL column 'testing.testing_id'
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
'testing_pkey' for table 'testing'
CREATE TABLE
junk=> alter table testing
junk-> alter column testing_id drop default;
ALTER TABLE


I'd be inclined to say that the bug here is that you shouldn't be
allowed to do ALTER COLUMN DROP DEFAULT (nor SET DEFAULT for that
matter) on a SERIAL column.  The default expression is part of the
implementation of SERIAL, not an independently tweakable entity.


Tom -

I am actually inclined to agree with you. This is not an issue I see 
coming up for us again, so making it work as you described above seems 
to me does not impact us negatively at all. This was a fluke for us as 
our application code was dependent on the manner in which the way 
pre-7.3 versions of PostgreSQL truncated sequence names. In running 
tests on the software we wrote to migrate our 7.2 databases to become 
7.3 databases we just happened to stumble across this issue by accident 
(literally).

Regardless, my thinking had been that I was looking at an INT with a 
DEFAULT set, in which case I think this would be a bonified bug, thus my 
report. However, it makes more sense to consider the column to be of 
type SERIAL, despite the labelling. Perhaps the best result would be to 
not allow the DROP DEFAULT on a SERIAL column and to label the SERIAL 
column as such (as opposed to an INT with DEFAULT).

Thanks, as always, for taking the time to consider my posting and respond.

- Tara

--
Tara Piorkowski
System Administrator, vilaj.com, LLC



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Bug in Dependencies Code in 7.3.x?

[Tom Lane]

Tara Piorkowski <[EMAIL PROTECTED]> writes:
> junk=> create table testing
> junk-> (testing_id serial not null primary key);
> NOTICE:  CREATE TABLE will create implicit sequence 
> 'testing_testing_id_seq' for SERIAL column 'testing.testing_id'
> NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
> 'testing_pkey' for table 'testing'
> CREATE TABLE
> junk=> alter table testing
> junk-> alter column testing_id drop default;
> ALTER TABLE

I'd be inclined to say that the bug here is that you shouldn't be
allowed to do ALTER COLUMN DROP DEFAULT (nor SET DEFAULT for that
matter) on a SERIAL column.  The default expression is part of the
implementation of SERIAL, not an independently tweakable entity.

We could make it work sort of the way Tara is expecting if the
dependency link were to associate the sequence object with the
column's default expression, and not with the column itself ---
but if we did that, then the above DROP DEFAULT would probably make
the sequence object go away too, which is still not quite what
she's expecting.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] why was libpq.so's version number bumped?

[Neil Conway]

Christopher Kings-Lynne said:
> There have been HEAPS of security fixes between 7.2 and 7.3.

That's only the case if your definition of a "security fix" is pretty fast
and loose -- as yours seems to be.

> Depending
> on your definition of security.  eg. Going 'select cash_out(2);' on any
> 7.2 server and below will crash the backend.

If you consider that a security flaw, there are still innumerable problems
of a very similar nature in 7.3 or 7.4-devel (*any* situation in which an
untrusted client can execute arbitrary SQL will allow for resource
exhaustion, at the very least).

By a more reasonable definition of "security flaw", I'm not aware of any
significant outstanding problems in 7.2.3 -- there are a bunch of buffer
handling fixes in 7.3, but they were made for the sake of correctness
(a.k.a. paranoia), not necessarily to fix an actual vulnerability.

Cheers,

Neil



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] MOVE strangeness

[Manfred Koizar]

On Sun, 29 Dec 2002 16:39:37 -0800, Kevin Brown <[EMAIL PROTECTED]>
wrote:
>> > Okay.  But then doesn't it make sense for FETCH to fetch the contents
>> > of the row (and subsequent requested rows) that the cursor is
>> > currently on *then* move, and not the other way around?

>This model is extremely common and, IMO, sensible.  

OTOH, seeing a row *before* updating or deleting it is *extremely*
useful.  Here is what you are proposing:

SELECT * FROM t ORDER BY id;
id | txt
---+---
 1 | leave me alone
 2 | delete me
 3 | keep me

BEGIN;
DECLARE c CURSOR FOR SELECT * FROM t ORDER BY id;
FETCH 1 FROM c;
id | txt
---+---
 1 | leave me alone

-- ok, leave it alone ...

FETCH 1 FROM c;
id | txt
---+---
 2 | delete me

-- got it!  (really??)
DELETE FROM t WHERE CURRENT OF c;
COMMIT;

SELECT * FROM t ORDER BY id;
id | txt
---+---
 1 | leave me alone
 2 | delete me

-- oops!!

> just as you'd expect

No, not me.  Would *you* expect this?  If you really want to draw an
analogy between databases and editors, compare rows to lines, not
characters.  Now imagine an editor window just one line high, then it
is clear that after a row is brought into the window you don't want
the cursor to silently advance to the next (invisible) row.

Servus
 Manfred

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[HACKERS] Bug in Dependencies Code in 7.3.x?

[Tara Piorkowski]

I've found a situation that doesn't look correct to me in 7.3.1 (and 
presumably 7.3 as well). If I alter a column so that it no longer uses a 
sequence for default values and then try to drop the aforementioned 
sequence, the dependency checking code does not allow me to drop the 
sequence on the basis that it is still deing used. As I have removed the 
default setting, however, this should not be the case, as far as I can 
tell. The following illustrates my finding.

junk=> create table testing
junk-> (testing_id serial not null primary key);
NOTICE:  CREATE TABLE will create implicit sequence 
'testing_testing_id_seq' for SERIAL column 'testing.testing_id'
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
'testing_pkey' for table 'testing'
CREATE TABLE
junk=> \d
  List of relations
 Schema |  Name  |   Type   | Owner
++--+
 public | testing| table| tara
 public | testing_testing_id_seq | sequence | tara
(2 rows)

junk=> \d testing
 Table "public.testing"
   Column   |  Type   |Modifiers 

+-+-
 testing_id | integer | not null default 
nextval('public.testing_testing_id_seq'::text)
Indexes: testing_pkey primary key btree (testing_id)

junk=> alter table testing
junk-> alter column testing_id drop default;
ALTER TABLE
junk=> \d testing
  Table "public.testing"
   Column   |  Type   | Modifiers
+-+---
 testing_id | integer | not null
Indexes: testing_pkey primary key btree (testing_id)

junk=> drop sequence testing_testing_id_seq;
ERROR:  Cannot drop sequence testing_testing_id_seq because table 
testing column testing_id requires it
You may drop table testing column testing_id instead

--
Tara Piorkowski
System Administrator, vilaj.com, LLC



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] why was libpq.so's version number bumped?

[Dan Langille]

On Mon, 30 Dec 2002, Palle Girgensohn wrote:

> --On måndag, december 30, 2002 06.35.22 -0500 Dan Langille
> <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 30 Dec 2002, Christopher Kings-Lynne wrote:
> >
> >> ps. Why is Postgres 7.3 still in ports/databases/postgresql-devel ??
> >
> > I forgot one other possible answer: perhaps the port maintainer is taking
> > a well deserved holiday?
>
> :)  Well, not really, it is because of the port freeze. I don't maintain
> the -devel port, Sean Chittenden does. It seems logical that he maintains
> it, since he has commit rights to the ports tree. It was used during
> postgresql's beta phase, and it will be removed after the port freeze, only
> to resurrect at the next beta phase. This is the plan, anyway. :)

I liked and used the -devel port.  I think the concept should be retained.

> > Since going from 7.2 to 7.3 is a significant upgrade, the FreeBSD guys
> > would probablyu be right tho to refuse such a major upgrade...  Still,
> > it's a pity though.  Postgres 7.3 has been tested and works fine on
> > FreeBSD 5.
>
> True, perhaps, but if the old version has security flaws... Also, since 5.0
> is a new major version for FreeBSD, most binaries need relinking to fully
> utilize the new system - wouldn't it be clever to have the new postgres
> libpq relinked at the same time as well...?

What about the other 8000 or so ports?  Should we halt FreeBSD development
so they all have the latest version as well?  I think not. At some point,
a line must be drawn.

> --On måndag, december 30, 2002 06.24.38 -0500 Dan Langille
> <[EMAIL PROTECTED]> wrote:
> >
> > If anything, the ports tree on the CD will contain a reference to 7.2.3.
> > PostgreSQL itself is not shipped.  The ports tree can be cvsup'd to the
> > latest, when the cvs repository is updated.  At present there is a ports
> > freeze.  This is the normal situation just prior to a major release.
>
> Well, on the DVD or four-disk-set, there will be a package of 7.2.3, so in
> a way, postgreSQL is actually shipped...

Given that there are almost 8000 ports, it is simply not practical to hold
everything up while we get the latest of everything.  Exceptions are
allowed, but again, I don't have a problem with it.

> Well, we'll see. 7.3 has been in gnats for some time now. I'll send in the
> new 7.3.1 and send a few emails lobbying for it, and let the guys
> responsible decide if it a pre- or post-5.0 port...

I don't see it as a big deal.  It's just a ports tree entry going out with
5.  That entry can be cvsup'd and updated to the latest and greatest.


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] why was libpq.so's version number bumped?

[Palle Girgensohn]

--On måndag, december 30, 2002 06.35.22 -0500 Dan Langille 
<[EMAIL PROTECTED]> wrote:

On Mon, 30 Dec 2002, Christopher Kings-Lynne wrote:


ps. Why is Postgres 7.3 still in ports/databases/postgresql-devel ??


I forgot one other possible answer: perhaps the port maintainer is taking
a well deserved holiday?


:)  Well, not really, it is because of the port freeze. I don't maintain 
the -devel port, Sean Chittenden does. It seems logical that he maintains 
it, since he has commit rights to the ports tree. It was used during 
postgresql's beta phase, and it will be removed after the port freeze, only 
to resurrect at the next beta phase. This is the plan, anyway. :)

I now know the reason for bumping the so version number. Thanks!


Since going from 7.2 to 7.3 is a significant upgrade, the FreeBSD guys
would probablyu be right tho to refuse such a major upgrade...  Still,
it's a pity though.  Postgres 7.3 has been tested and works fine on
FreeBSD 5.


True, perhaps, but if the old version has security flaws... Also, since 5.0 
is a new major version for FreeBSD, most binaries need relinking to fully 
utilize the new system - wouldn't it be clever to have the new postgres 
libpq relinked at the same time as well...?

--On måndag, december 30, 2002 06.24.38 -0500 Dan Langille 
<[EMAIL PROTECTED]> wrote:

If anything, the ports tree on the CD will contain a reference to 7.2.3.
PostgreSQL itself is not shipped.  The ports tree can be cvsup'd to the
latest, when the cvs repository is updated.  At present there is a ports
freeze.  This is the normal situation just prior to a major release.


Well, on the DVD or four-disk-set, there will be a package of 7.2.3, so in 
a way, postgreSQL is actually shipped...

Well, we'll see. 7.3 has been in gnats for some time now. I'll send in the 
new 7.3.1 and send a few emails lobbying for it, and let the guys 
responsible decide if it a pre- or post-5.0 port...

Cheers,
Palle


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] why was libpq.so's version number bumped?

[Dan Langille]

On Mon, 30 Dec 2002, Christopher Kings-Lynne wrote:

> ps. Why is Postgres 7.3 still in ports/databases/postgresql-devel ??

I forgot one other possible answer: perhaps the port maintainer is taking
a well deserved holiday?


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] why was libpq.so's version number bumped?

[Dan Langille]

On Mon, 30 Dec 2002, Christopher Kings-Lynne wrote:

> Since going from 7.2 to 7.3 is a significant upgrade, the FreeBSD guys would
> probablyu be right tho to refuse such a major upgrade...  Still, it's a pity
> though.  Postgres 7.3 has been tested and works fine on FreeBSD 5.

FreeBSD uses something called a ports tree.  This is quite separate from
the source tree, which is used to create FreeBSD 5.  The issue is not
whether or not 7.3 has been tested and works.  When you have nearly
8000 ports, it makes sense to freeze them just prior to a release.  Code
freezes are standard practice.  I which more projects used them.

> ps. Why is Postgres 7.3 still in ports/databases/postgresql-devel ??
> Actually, maybe it was a good thing since if 7.3.1 becomes the new standard
> port people won't be bitten so much by the library version bump.

My guess: because of the port freeze now in effect.


---(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 get through to the mailing list cleanly

Re: [HACKERS] why was libpq.so's version number bumped?

[Dan Langille]

On Mon, 30 Dec 2002, Palle Girgensohn wrote:

> One of the reasons I ask is, if it is a good reason, like say "security",
> maybe I can persuade the FreeBSD port responsible guys to bring the port
> into the upcoming FreeBSD 5.0 release. The port freeze was introduced just
> before pg-7.3 was released, so nothing new will be admitted unless it is a
> security fix, more or less, which means FreeBSD 5.0 will probably ship with
> 7.2.3, which would be a disappointment...

If anything, the ports tree on the CD will contain a reference to 7.2.3.
PostgreSQL itself is not shipped.  The ports tree can be cvsup'd to the
latest, when the cvs repository is updated.  At present there is a ports
freeze.  This is the normal situation just prior to a major release.


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org