Thread: Debian packages of 7.4
Debian packages of 7.4 have been uploaded to Debian's experimental archive. Because of certain issues with interlocking dependencies, I will not move them to unstable until version 7.3.4-9 is accepted into the testing distribution. This is not a reflection on 7.4's quality but the result of a long-standing blockage in the movement of packages into testing caused by the perl packages. Unfortunately, this means that 7.4 packages won't get built for architectures other than i386 until that blockage gets cleared. You can check progress on this at http://bjorn.haxx.se/debian/testing.pl?package=postgresql Debian users wishing to install the new PostgreSQL packages should add experimental to their apt/sources.list and use the -t option to apt-get. Package list: postgresql_7.4-1_i386.deb 3483.1 kB postgresql-plr_7.4-1_i386.deb 66.7 kB postgresql-doc_7.4-1_all.deb 2106.9 kB postgresql-dev_7.4-1_i386.deb 484.7 kB postgresql-contrib_7.4-1_i386.deb 556.7 kB postgresql-client_7.4-1_i386.deb 471.5 kB odbc-postgresql_7.4-1_i386.deb 152.8 kB libpq3_7.4-1_i386.deb 104.2 kB libpgtcl_7.4-1_i386.deb 63.4 kB libpgtcl-dev_7.4-1_i386.deb 41.8 kB libpgperl_7.4-1_i386.deb 108.2 kB libpgeasy_7.4-1_i386.deb 31.3 kB libpgeasy-dev_7.4-1_i386.deb 30.7 kB libecpg4_7.4-1_i386.deb 79.6 kB libecpg-dev_7.4-1_i386.deb 186.8 kB Those packages were built with dependencies on recent packages in unstable. A version built for woody (stable) is available at http://people.debian.org/~elphick/debian Please note that the python packages have been dropped from this build, since the PyGreSQL source tree is now independent. Another maintainer will take those on. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "A Song for the sabbath day. It is a good thing to give thanks unto the LORD, and to sing praises unto thy name, O most High." Psalms 92:1
Hi,
A colleague and I noticed that MySQL allows this:
CREATE TABLE ` ` ( ` ` INT NOT NULL );
A table with a space as its name and a space as a column name.
We were quite surprised by that and we tested it on postgresql at once
to see whether it was the only one to do so.
Now we were even more surprised that postgresql allows this aswell:
kb=# CREATE TABLE " " (" " int not null);
CREATE TABLE
kb=# \d " "
Table "public. "
Column | Type | Modifiers
--------+---------+-----------
| integer | not null
Is this per spec, a bug or intended behaviour?
Best regards,
Arjen van der Meijden
Arjen van der Meijden writes: > Is this per spec, a bug or intended behaviour? Yes, no, yes. -- Peter Eisentraut peter_e@gmx.net
Oliver Elphick writes: > Please note that the python packages have been dropped from this build, > since the PyGreSQL source tree is now independent. Another maintainer > will take those on. Then why are plr, odbc, pgeasy and pgperl still in there? Those have been removed a longer time ago, or were never even in there in the first place. -- Peter Eisentraut peter_e@gmx.net
On Tue, 2003-11-18 at 12:59, Peter Eisentraut wrote: > Oliver Elphick writes: > > > Please note that the python packages have been dropped from this build, > > since the PyGreSQL source tree is now independent. Another maintainer > > will take those on. > > Then why are plr, odbc, pgeasy and pgperl still in there? Those have been > removed a longer time ago, or were never even in there in the first place. plr needs to build in the source tree, so the easiest way to do that is to include it in the source. The same goes (or did go) for the others. I'm aware that odbc no longer needs that and shifting it into a separate source package is on my list of things to do. Some things just happen by inertia until I get prompted to change them. I'm dropping python packages (rather than making a new source package) because I have never used python at all and can't support it and there is another maintainer willing to take them on. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "A Song for the sabbath day. It is a good thing to give thanks unto the LORD, and to sing praises unto thy name, O most High." Psalms 92:1
* Oliver Elphick (olly@lfix.co.uk) wrote:
> On Tue, 2003-11-18 at 12:59, Peter Eisentraut wrote:
> > Oliver Elphick writes:
> >
> > > Please note that the python packages have been dropped from this build,
> > > since the PyGreSQL source tree is now independent. Another maintainer
> > > will take those on.
> >
> > Then why are plr, odbc, pgeasy and pgperl still in there? Those have been
> > removed a longer time ago, or were never even in there in the first place.
>
> plr needs to build in the source tree, so the easiest way to do that is
> to include it in the source. The same goes (or did go) for the others.
I don't think this is really the case. I was working on repackaging
PostgreSQL for Debian to show this but got busy with other things.
Stephen
Attachment
On Tue, 2003-11-18 at 13:19, Stephen Frost wrote: > > plr needs to build in the source tree, so the easiest way to do that is > > to include it in the source. The same goes (or did go) for the others. > > I don't think this is really the case. I was working on repackaging > PostgreSQL for Debian to show this but got busy with other things. Did you get anywhere with it? When the PL/R package was requested, it was easiest for me to throw it in with the postgresql source package, but I'm quite willing to separate it out if it doesn't mean I have to rewrite parts of PL/R. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "A Song for the sabbath day. It is a good thing to give thanks unto the LORD, and to sing praises unto thy name, O most High." Psalms 92:1
* Oliver Elphick (olly@lfix.co.uk) wrote:
> On Tue, 2003-11-18 at 13:19, Stephen Frost wrote:
> > > plr needs to build in the source tree, so the easiest way to do that is
> > > to include it in the source. The same goes (or did go) for the others.
> >
> > I don't think this is really the case. I was working on repackaging
> > PostgreSQL for Debian to show this but got busy with other things.
>
> Did you get anywhere with it? When the PL/R package was requested, it
> was easiest for me to throw it in with the postgresql source package,
> but I'm quite willing to separate it out if it doesn't mean I have to
> rewrite parts of PL/R.
I had gotten some of the pieces to build outside just using what the
postgresql-dev package provides, I don't remember if plr was one of
them. Tell you what, I'll figure out today if it'll work to build it
outside the source tree if you do the split work. :)
Stephen