[GENERAL] weakness and strenghts of PG
Hi (I have posted this question to pg_advocacy as well, but I want to get an answer or a discussion from this group as well, separate from the advocacy group and background) I am researching an advocation paper on Postgres. Basically I would like to make a list of the most important strengths and weaknesses of Postgres compared to a couple of other major databases. The aim is to have a factual tehcnical background for when advocating Postgres to potential users. Specifically I would like to compare: - PG - MySql - Oracle - MS SQL server - Firebird the facts I am looking for is about the core functionality and use application aspects. while thae answers I am looking for is for example whether - one db more or less suited for GIS or warehouse etc - one db is not well suited for performance operations - if there are types of operations a database is not good at, or conversely, is extremely good at. I know this is pretty vague, but just focus on what weakenesses and strengths the different db's has, compared to each other. And I will try to ask the right questions based on that. regards thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] updated unofficial debian packages
Hi, Once again, I'm providing "bleeding etch" Debian packages: 8.3.6, 8.2.12 and 8.1.16 for Debian etch as well as for Debian lenny (or newer). However, please note that these did not run through any of the standard Debian quality assurance procedures. Use them at your own risk. For the experimental packages (for lenny or newer) use: deb http://packages.bluegap.ch/debian/postgres experimental main In addition to the newest 8.3.6 release, you also get 8.2 and 8.1 packages for lenny from there. >From those packages, I've "backported" to etch. Note however, that these packages are not considered "backports" in the Debian Backports sense. The main difference between the two variants offered is that those for etch are built against TCL 8.4 (instead of the newer 8.5 for lenny). You get the etch variants with: deb http://packages.bluegap.ch/debian/postgres etch main >From there, you get 8.3 (somewhat like from the official backports), 8.2 (which is no longer available from the backports) and a bleeding edge 8.1 package for etch. I've changed the directory structure, please stop using www.bluegap.ch/debian. I'm striving to keep supporting 8.1 and 8.2 for experimental, to ease upgarding without forcing users to upgrade their Postgres version. I really like the way Debian can handle multiple Postgres versions in parallel. Let's make use of that nice feature! Adding 8.3 to the mix is rather a convenience, as Martin Pitt already maintains 8.3 for experimental. Very much the same holds true for 8.1 for etch. All packages offered here have a debian revision of 0~bluegap1 or 0~bluegap1+etch1. Once an official Debian or an official backport package of the same Postgres version comes out, that overrides these due to a higher version number. Enjoy! Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] column name with plpgsql
Hi, i have a table which can be altered with several additional column. How can i test under plpgsql if a particular column already exists ? thx. -- Alain --- Windows XP x64 SP2 / Fedora 10 KDE 4.2 PostgreSQL 8.3.5 / MS SQL server 2005 Apache 2.2.10 PHP 5.2.6 C# 2005-2008
Re: [GENERAL] column name with plpgsql
information_schema is the keyword here. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] column name with plpgsql
On 07/02/2009 14:26, Alain Roger wrote: > i have a table which can be altered with several additional column. How can > i test under plpgsql if a particular column already exists ? select 1 from information_schema.columns where table_name = 'your_table_name_here' and column_name = 'your_column_name_here'; HTH, Ray. -- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland r...@iol.ie Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] column name with plpgsql
Thanks a lot Raymond it works well. On Sat, Feb 7, 2009 at 3:32 PM, Raymond O'Donnell wrote: > On 07/02/2009 14:26, Alain Roger wrote: > > > i have a table which can be altered with several additional column. How > can > > i test under plpgsql if a particular column already exists ? > > select 1 from information_schema.columns > where table_name = 'your_table_name_here' > and column_name = 'your_column_name_here'; > > HTH, > > Ray. > > -- > Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland > r...@iol.ie > Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals > -- > -- Alain --- Windows XP x64 SP2 / Fedora 10 KDE 4.2 PostgreSQL 8.3.5 / MS SQL server 2005 Apache 2.2.10 PHP 5.2.6 C# 2005-2008
Re: [GENERAL] how to find foreign key details (column, that is)
Karsten Hilbert wrote: > On Wed, Jan 21, 2009 at 01:49:44PM -0500, Bruce Momjian wrote: > > > Tom Lane wrote: > > > Karsten Hilbert writes: > > > > This is what my 8.3 manual says: > > > > > > > conkey ? int2[] ? pg_attribute.attnum ? If a table constraint, list of > > > > columns which the constraint constrains ? > > > > > > > From that I wouldn't have figured it'd apply to foreign keys > > > > as well. So I assume it is fair to say that "foreign keys > > > > are one type of table constraint", right ? > > > > > > Right. I think what the comment is actually trying to point out is that > > > conkey isn't relevant to domain constraints, which also appear in > > > pg_constraint. > > > > Can someone come up with better documentation wording for conkey? I > > can't: > > > > > > http://developer.postgresql.org/pgdocs/postgres/catalog-pg-constraint.html > > How about adding a second line: > > "Note: since foreign keys are table constraints, applies to those, too." > > or > > "If a foreign key, list of columns referencing the target table" > > (note, "referencing" as opposed to "referenced by" as in confkey) I went a different direction with the documentation; I simplified the wording and made it more explicit; attached and applied. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/catalogs.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v retrieving revision 2.194 diff -c -c -r2.194 catalogs.sgml *** doc/src/sgml/catalogs.sgml 4 Feb 2009 21:30:41 - 2.194 --- doc/src/sgml/catalogs.sgml 7 Feb 2009 14:52:38 - *** *** 1983,1989 conkey int2[] pg_attribute.attnum ! If a table constraint, list of columns which the constraint constrains --- 1983,1989 conkey int2[] pg_attribute.attnum ! If a table constraint (including a foreign key), list of the constrained columns -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Install Postgre while installing Other software.
Hi all! I'm trying to use Postgre as a DataBase manager of a Software I'm developing. I would like to know how to integrate an installation of Postgre in the installation of my own software. I mean, I need to firstly install Postgre, and when it finishes The rest of the installation of my software would continue. I've done some test with postgresql-8.3.5-1-windows.exe (on-click installer) but when it finishes and tries to run the server it crashes. Do any of you knows why this occurs?. I tried this version because I think it would be easiest for the user because It only shows one or two windows to the users, and they dont need to select many options. Do you have any experience in the distribution of a Postgre installation in your own developed software? How would you do it? Thank you in advance for your help. Best, Iñigo.
Re: [GENERAL] Install Postgre while installing Other software.
On 07/02/2009 15:40, Iñigo Barandiaran wrote: > I'm trying to use Postgre as a DataBase manager of a Software I'm > developing. I would like to know how to integrate an installation of Postgre > in the installation of my own software. I mean, I need to firstly install The community installer (pgInstaller) has a silent-install option which I understand is intended for just this scenario. BTW, the accepted abbreviation of PostgreSQL is "postgres", not "postgre". Ray. -- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland r...@iol.ie Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Install Postgre while installing Other software.
Hi Raymond! Thanks for your answer. I'm going to take a look to the silent option you mentioned. Any link related with this topic would be very appreciated. Thanks in advance! Best, 2009/2/7 Raymond O'Donnell > On 07/02/2009 15:40, Iñigo Barandiaran wrote: > > I'm trying to use Postgre as a DataBase manager of a Software I'm > > developing. I would like to know how to integrate an installation of > Postgre > > in the installation of my own software. I mean, I need to firstly install > > The community installer (pgInstaller) has a silent-install option which > I understand is intended for just this scenario. > > BTW, the accepted abbreviation of PostgreSQL is "postgres", not "postgre". > > Ray. > > > -- > Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland > r...@iol.ie > Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals > -- >
Re: [GENERAL] encoding of PostgreSQL messages
Can someone comment on this?
---
Hiroshi Inoue wrote:
> Hi,
>
> This topic seems to be related to the bug report
> [ODBC] Localized error messages, wrong charset
> .
>
> Bruce Momjian wrote:
> > Added to TODO:
> >
> > Improve encoding of connection startup messages sent to the client
> >
> > Currently some authentication error messages are sent in the server
> > encoding
>
> It it true ?
> IIRC the backend knows nothing about the server encoding in
> authentication phase.
>
> Psqlodbc Unicode driver sends connection startup message which
> contains the client_encoding(=UTF8) guc parameter. Attached is
> a trial patch so that the psqlodbc Unicode driver can get
> properly localized password error messages.
>
> regards,
> Hiroshi Inoue
> Index: postmaster/postmaster.c
> ===
> RCS file: /projects/cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
> retrieving revision 1.570
> diff -c -c -r1.570 postmaster.c
> *** postmaster/postmaster.c 4 Jan 2009 22:19:59 - 1.570
> --- postmaster/postmaster.c 30 Jan 2009 14:05:35 -
> ***
> *** 1552,1557
> --- 1552,1560
>
> pstrdup(nameptr));
> port->guc_options = lappend(port->guc_options,
>
> pstrdup(valptr));
> + if (stricmp(nameptr, "client_encoding") == 0 &&
> + stricmp(valptr, "UTF8") == 0)
> +
> bind_textdomain_codeset(PG_TEXTDOMAIN("postgres"), "UTF-8");
> }
> offset = valoffset + strlen(valptr) + 1;
> }
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Strange limit and offset behaviour....
I have the following sql: SELECT * from table order by dato asc limit 20 offset 0 This gives me different rows than the 20 first rows when running the following sql: SELECT * from table order by dato asc Shouldn't the 20 first rows in the second sql statment be the same 20 rows that is returned in the first statement or am I missing something? Regards, BTJ -- --- Bjørn T Johansen b...@havleik.no --- Someone wrote: "I understand that if you play a Windows CD backwards you hear strange Satanic messages" To which someone replied: "It's even worse than that; play it forwards and it installs Windows" --- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Strange limit and offset behaviour....
> > I have the following sql: > > SELECT * from table order by dato asc limit 20 offset 0 > > > This gives me different rows than the 20 first rows when running the > following sql: > > SELECT * from table order by dato asc > > > Shouldn't the 20 first rows in the second sql statment be the same 20 > rows that is returned in the first statement > or am I missing something? > Not necessarily. In your example query, if "dato" was not a unique column, and there were some duplicates, the "top 20" values is not a defined set. Adding the offset clause might cause a different query plan, resulting in a different ordering of the duplicate values. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Strange limit and offset behaviour....
On Sat, 7 Feb 2009 15:49:49 -0600 "Adam Rich" wrote: > > > > I have the following sql: > > > > SELECT * from table order by dato asc limit 20 offset 0 > > > > > > This gives me different rows than the 20 first rows when running the > > following sql: > > > > SELECT * from table order by dato asc > > > > > > Shouldn't the 20 first rows in the second sql statment be the same 20 > > rows that is returned in the first statement > > or am I missing something? > > > > Not necessarily. In your example query, if "dato" was not a unique > column, and there were some duplicates, the "top 20" values is not > a defined set. Adding the offset clause might cause a different > query plan, resulting in a different ordering of the duplicate values. > > I found out that if I created an index on the dato field, then I got the same 20 rows... Does that make sense or is it just a coincedense? BTJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Strange limit and offset behaviour....
On Sat, Feb 7, 2009 at 9:57 PM, Bjørn T Johansen wrote: >> > SELECT * from table order by dato asc is the field 'dato' the same in both cases ? if so - you're goood just compare: select dato from table order by dato asc limit 10; with select dato from table order by dato asc limit 10 offset 0; -- GJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Strange limit and offset behaviour....
On Sat, 7 Feb 2009 22:03:37 + Grzegorz Jaśkiewicz wrote: > On Sat, Feb 7, 2009 at 9:57 PM, Bjørn T Johansen wrote: > >> > SELECT * from table order by dato asc > > is the field 'dato' the same in both cases ? if so - you're goood > just compare: > > select dato from table order by dato asc limit 10; > with > select dato from table order by dato asc limit 10 offset 0; > > > yes, they are the same... And returns the same, now when I have created an index for the dato field... BTJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Strange limit and offset behaviour....
On Sat, Feb 7, 2009 at 10:22 PM, Bjørn T Johansen wrote: > yes, they are the same... And returns the same, now when I have created an > index for the dato field... so, ales in ordunung ;) you just have to choose different sorting key -- GJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pet Peeves?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> What logic would lead someone to separate pg_config from everything else? >> Do people often just install the server and nothing else? Then what? > This is actually *required* by Debian/Ubuntu packaging rules. > The development environment must be packaged separately from shared libraries > like libpq or else major snafus arise when a new soversion of libpq comes out. > You need to be able to have both versions installed simultaneously (in case > you have programs which require both) but that won't work if they both contain > things like header files or executables. I'm not sure I follow this. What makes pg_config so different from psql? I can't imagine why it's not simply treated the same as pg_dump and psql. It's certainly annoying to have to install a whole seperate package just to have access to it. >> BTW I ran into the need for pg_config upon installing DBD::Pg. >> Maybe DBD::Pg maintainer problem? > Installing a package for DBD::Pg or building it? The former would indeed be a > package bug. AFAIK, no package has that problem. If there is one, someone raise a bug. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200902072126 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkmOQz8ACgkQvJuQZxSWSsh/1QCg/fTaxS2yT9tiyKEhb+NGLUkl uhkAn0jEHN6NxxynaeTNEQ8+3bHrtCv/ =RKHl -END PGP SIGNATURE- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pet Peeves?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > * Letter options in psql, pg_dump[all], pg_restore aren't consistent > and can easily steer you very wrong. I'm looking at you, -d. Amen! > So, what do people say? Is Postgres perfect in your world or does > it do some things which rub you the wrong way? You can check the archives for more things I've found annoying in the past, but might as well put out a quick list here for posterity: * We're using md5 as the default hash function. Lame. * We don't have any other builtin encryption/hash stuff other than md5. * Many more things should be built-in, rather than as contrib or worse. Make them 'installable' like procedural languages if you must, but they have to go in easier. * pgfoundry is still a mess. 'nuff said. * We lost years worth of community shared knowledge when planetpostgresql went down and the owner won't let people restore their links (e.g. a simple Apache redirect). * psql is not backwards compatible * In-place upgrade. Regular dump/restore could be better too. * The resistance to changing the name officially back to "Postgres". * The way patches must often be fought for before acceptance. * The community is scared of change. Exhibit A: git * Lack of pragmatism at times: real-world DBA work vs. ivory tower pontification. * Deferred constraints * psql doesn't do multi-line readline * The horrible defaults in postgresql.conf * The horrible commenting in postgresql.conf * The crappy 8kb GUC unit sizes * Slow pace of libpq: no binary, no partial result sets * Logging could be a lot more flexible and fine-grained. Imagine being able to have slow queries from database X go to a separate log file. * Horrible bike shedding and making simple solutions complicated. * Would like to see information_schema expanded. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200902072156 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkmOSfMACgkQvJuQZxSWSsgNIQCgtp9rDWLVyeTDjIvFw+lPWyju B9kAn0e3mvpaKcu19qZS1qdJdA+vLBfT =KYSj -END PGP SIGNATURE- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pet Peeves?
In the case of DBD::Pg it seems that it just uses the output of pg_config. It seems absurd that that information can't be stored in psql. There must be some good reason that it's not. Is it because psql is stripped? At least the build information (which pg_config spits out) could be stored in a text file that psql knows about and then psql --buildopts would give you that information. On Sun, 8 Feb 2009 02:28:40 - "Greg Sabino Mullane" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > > >> What logic would lead someone to separate pg_config from everything else? > >> Do people often just install the server and nothing else? Then what? > > > This is actually *required* by Debian/Ubuntu packaging rules. > > > The development environment must be packaged separately from shared > > libraries > > like libpq or else major snafus arise when a new soversion of libpq comes > > out. > > You need to be able to have both versions installed simultaneously (in case > > you have programs which require both) but that won't work if they both > > contain > > things like header files or executables. > > I'm not sure I follow this. What makes pg_config so different from psql? I > can't > imagine why it's not simply treated the same as pg_dump and psql. It's > certainly > annoying to have to install a whole seperate package just to have access to > it. > > >> BTW I ran into the need for pg_config upon installing DBD::Pg. > >> Maybe DBD::Pg maintainer problem? > > > Installing a package for DBD::Pg or building it? The former would indeed be > > a > > package bug. > > AFAIK, no package has that problem. If there is one, someone raise a bug. > > - -- > Greg Sabino Mullane g...@turnstep.com > PGP Key: 0x14964AC8 200902072126 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -BEGIN PGP SIGNATURE- > > iEYEAREDAAYFAkmOQz8ACgkQvJuQZxSWSsh/1QCg/fTaxS2yT9tiyKEhb+NGLUkl > uhkAn0jEHN6NxxynaeTNEQ8+3bHrtCv/ > =RKHl > -END PGP SIGNATURE- > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pet Peeves?
On Feb 7, 2009, at 7:09 PM, rhubbell wrote: In the case of DBD::Pg it seems that it just uses the output of pg_config. It seems absurd that that information can't be stored in psql. There must be some good reason that it's not. Is it because psql is stripped? At least the build information (which pg_config spits out) could be stored in a text file that psql knows about and then psql --buildopts would give you that information. But what would you do with the information then? Most anything (including building DBD::Pg) that wants that data is going to need the developer package. Cheers, Steve -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pet Peeves?
On Sat, Feb 7, 2009 at 7:57 PM, Greg Sabino Mullane wrote: > * psql doesn't do multi-line readline I thought it started doing that in 8.2 or 8.3. At least on linux. > * Logging could be a lot more flexible and fine-grained. Imagine being able to > have slow queries from database X go to a separate log file. This, very much this. I would kill to be able to have each db in a cluster have its own logging, settings, shared_buffers, etc. The whole shared mostly environment makes scaling to > 1 db on a server a troublesome task -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] weakness and strenghts of PG
Here is a decent article comparing different db implementations. http://troels.arvin.dk/db/rdbms/ It doesn't include firebird, but does include DB2 and informix. Some of the deficiencies of Postges addressed will be rectified in the upcoming 8.4 release. In my opinion the best two databases out there to develop on are Postgres and Oracle. Oracle has the richest feature set of any database, but Postgres is easier to work with. Take arrays for instance. Oracle has 3 different implementations of arrays (varrays, nested tables & assoc arrays) Postgres only has 1 array type. But using Oracle arrays is so complicated I hardly ever use them while Postgres' arrays are dead easy and extremely powerful. I think the biggest weakness of Postgres is advocacy and integration. We have current versions of popular distributions shipping with ancient versions of Postgres. Or try finding a web host that runs the current version of Postgres. The other day I was going to do a small project in Ruby and Postgres and I spent a couple hours trying to get Ruby talking to Postgres on Windows. It's going to be impossible for Postgres to compete with MySQL while this continues. Artacus Hi (I have posted this question to pg_advocacy as well, but I want to get an answer or a discussion from this group as well, separate from the advocacy group and background) I am researching an advocation paper on Postgres. Basically I would like to make a list of the most important strengths and weaknesses of Postgres compared to a couple of other major databases. The aim is to have a factual tehcnical background for when advocating Postgres to potential users. Specifically I would like to compare: - PG - MySql - Oracle - MS SQL server - Firebird the facts I am looking for is about the core functionality and use application aspects. while thae answers I am looking for is for example whether - one db more or less suited for GIS or warehouse etc - one db is not well suited for performance operations - if there are types of operations a database is not good at, or conversely, is extremely good at. I know this is pretty vague, but just focus on what weakenesses and strengths the different db's has, compared to each other. And I will try to ask the right questions based on that. regards thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] weakness and strenghts of PG
Artacus wrote: > I think the biggest weakness of Postgres is advocacy and integration. We > have current versions of popular distributions shipping with ancient > versions of Postgres. Or try finding a web host that runs the current > version of Postgres. The other day I was going to do a small project in > Ruby and Postgres and I spent a couple hours trying to get Ruby talking > to Postgres on Windows. It's going to be impossible for Postgres to > compete with MySQL while this continues. True. These areas are the last to catch up because they require years of momentum; they do catch up, but it takes time. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pet Peeves?
On Sat, 7 Feb 2009 19:30:37 -0800 Steve Atkins wrote: > > On Feb 7, 2009, at 7:09 PM, rhubbell wrote: > > > In the case of DBD::Pg it seems that it just uses the output of > > pg_config. It seems absurd that that information can't be stored in > > psql. There must be some good reason that it's not. > > Is it because psql is stripped? > > > > At least the build information (which pg_config spits out) could be > > stored > > in a text file that psql knows about and then psql --buildopts would > > give you that information. > > But what would you do with the information then? Most anything > (including > building DBD::Pg) that wants that data is going to need the developer > package. Oh, that's right DBD::Pg needs to compile against the pg dev bits. > > Cheers, >Steve > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
