Top of my list would be:
1. Inability to do a PITR for a single database in a cluster.
2. Lack of support for Large Objects in master-slave replication.
3. Queries that I write are not corrected by postgres ;)
One last thing - it peeves me that many of the people on the forums are
so bloody cle
On Wed, Feb 11, 2009 at 4:45 PM, Grzegorz Jaśkiewicz wrote:
> On Wed, Feb 11, 2009 at 4:26 PM, Alvaro Herrera
> wrote:
>
>> Apparently nobody saw the talk ... ??
> http://blog.hagander.net/archives/137-FOSDEM-is-done.html
>
> Acording to that page, one of Greg's talks didn't happen. I wasn't
> th
On Wed, Feb 11, 2009 at 4:26 PM, Alvaro Herrera
wrote:
> Apparently nobody saw the talk ... ??
http://blog.hagander.net/archives/137-FOSDEM-is-done.html
Acording to that page, one of Greg's talks didn't happen. I wasn't
there, but was it the one ?
--
GJ
--
Sent via pgsql-general mailing lis
Peter Eisentraut wrote:
> Gregory Stark wrote:
>> I'm putting together a talk on "PostgreSQL Pet Peeves" for discussion at
>> FOSDEM 2009 this year.
>
> Perhaps you could post a conclusion to this, with some "worst of"
> statistics or something. I didn't see your talk, but I was getting a
> se
Gregory Stark wrote:
I'm putting together a talk on "PostgreSQL Pet Peeves" for discussion at
FOSDEM 2009 this year.
Perhaps you could post a conclusion to this, with some "worst of"
statistics or something. I didn't see your talk, but I was getting a
sense that the feedback seen on this lis
Richard Huxton wrote:
Gregory Stark wrote:
Steve Crawford writes:
3. Date handling
Sometimes I've got data with invalid dates and it would be great if it
could replace all the bad ones with, say "-00-00".
Oh dear $DEITY, no.
I think it would be best if we
Erik Jones escribió:
> One workaround I came up with a while back for that is to edit the stat
> file name to be in a separate directory under global (like
> /global/pg_stats/pgstat.stat) and mount a ramfs there. Of
> course, a custom compile isn't always an option but it removed a *ton*
>
drop user X casacde...
say x has an access to database Y, you have to revoke it before
dropping the user... takes ages.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> * psql doesn't do multi-line readline
> I thought it started doing that in 8.2 or 8.3. At least on linux.
It combines all lines into a single statement, which is handy, but things
like this still trip it up:
psql#> CREATE
psql-#> TAB
>
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
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 sep
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 (w
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
-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 y
-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
Alvaro Herrera wrote:
A trivial, stupid implementation is perhaps not too difficult. The
problem is getting the smarts right, i.e. an optimized version. You
certainly don't want to be executing a query against a large table for
every INSERT on another one, for example; it's better if if you can
On Feb 2, 2009, at 12:46 PM, wstrzalka wrote:
On Feb 2, 8:23 pm, br...@momjian.us (Bruce Momjian) wrote:
wstrzalka wrote:
* stat collector is really greedy by definition even when system is
idle, when you have really really many relations
I think this will be fixed in 8.4.
That would by g
Grzegorz Jaśkiewicz wrote:
also, how hard would it be to implement "CREATE ASSERTION", and where
do you see it (and maybe Tom could anwer that one too).
Would you say, it would be possible for someone with my knowledge of
postgresql internals (vague), but with very good C to do it
I think you c
Grzegorz Jaśkiewicz escribió:
> On Wed, Feb 4, 2009 at 9:09 PM, Peter Eisentraut wrote:
> > On Wednesday 04 February 2009 20:36:24 Grzegorz Jaśkiewicz wrote:
> >> I dream about db wide checks on tables, without need to write
> >> expensive triggers.
> >> Basically, something that would run a selec
Hi,
I think too that having the possibility of scheduling database maintenance
function right into the database would be a great feature. The first use case
that comes to my mind is this */5 cron job which runs psql just to clean out
old sessions and force a vacuum analyze.
On Wednesday 04 Feb
On Feb 5, 2009, at 6:08 AM, Greg Stark wrote:
On Wed, Feb 4, 2009 at 6:42 PM, Simon Riggs
wrote:
As A.M. says elsewhere, it would be good to have a trigger that
fired a
NOTIFY that was picked up by a scheduled job that LISTENs every 10
minutes for certain events.
We need a place for cod
also, how hard would it be to implement "CREATE ASSERTION", and where
do you see it (and maybe Tom could anwer that one too).
Would you say, it would be possible for someone with my knowledge of
postgresql internals (vague), but with very good C to do it
--
Sent via pgsql-general mailing list (pg
On Thu, 2009-02-05 at 11:08 +, Greg Stark wrote:
> The problem with trying to push everything into the database is that
> it ends up sucking your entire application into the database. That
> limits your choice of languages and tools, and also creates a huge
> bottleneck.
No, it allows you to
On Wed, Feb 4, 2009 at 9:09 PM, Peter Eisentraut wrote:
> On Wednesday 04 February 2009 20:36:24 Grzegorz Jaśkiewicz wrote:
>> I dream about db wide checks on tables, without need to write
>> expensive triggers.
>> Basically, something that would run a select query after
>> insert/update/delete an
On Wed, Feb 4, 2009 at 6:42 PM, Simon Riggs wrote:
>
> As A.M. says elsewhere, it would be good to have a trigger that fired a
> NOTIFY that was picked up by a scheduled job that LISTENs every 10
> minutes for certain events.
>
> We need a place for code that is *not* directly initiated by a user'
Mark Roberts wrote:
- It'd be nice if the query planner was more "stable" - sometimes the
queries run fast, and then sometimes they randomly take 2 hours for a
delete that normally runs in a couple of minutes.
I was going to stay silent, because my pet peeves were already covered or had been f
On Wednesday 04 February 2009 19:39:42 John DeSoi wrote:
> Somewhat related, it would be nice if columns had a unique identifier
> in the catalog rather than just a sequence number for the table. This
> would make it possible to distinguish between altering a column versus
> dropping/adding when co
On Wednesday 04 February 2009 20:36:24 Grzegorz Jaśkiewicz wrote:
> I dream about db wide checks on tables, without need to write
> expensive triggers.
> Basically, something that would run a select query after
> insert/update/delete and based on result commit or rollback.
> unless there's somethin
On Mon, Feb 2, 2009 at 4:54 PM, Christopher Browne wrote:
> - Stored procedures that can manage transactions (e.g. - contrast with
> present stored functions that forcibly live *inside* a transaction
> context; the point isn't functions vs procedures, but rather to have
> something that can do txn
On Thu, 2009-01-29 at 13:16 +, Gregory Stark wrote:
> I'm putting together a talk on "PostgreSQL Pet Peeves" for discussion at
> FOSDEM 2009 this year. I have a pretty good idea what some them are of course,
> but I would be interested to hear if people have any complaints from personal
> exper
On Wed, 2009-02-04 at 14:09 +0900, Craig Ringer wrote:
> Guy Rouillier wrote:
> > Craig Ringer wrote:
> >> An internal job scheduler with the ability to fire jobs on certain
> >> events as well as on a fixed schedule could be particularly handy in
> >> conjunction with true stored procedures tha
I dream about db wide checks on tables, without need to write
expensive triggers.
Basically, something that would run a select query after
insert/update/delete and based on result commit or rollback.
unless there's something like that already in SQL (I am not aware of
all features in sql2008 draft)
On Wed, Feb 04, 2009 at 12:37:31PM -0500, Guy Rouillier wrote:
> Karsten Hilbert wrote:
Craig, what kind of "events" are you thinking about? Triggers are
already pieces of code that run upon "certain events", namely
insert, update or delete events. What others do you have in mi
On Feb 3, 2009, at 3:41 PM, Peter Geoghegan wrote:
What about postgreSQL's inability to re-order columns?
Please don't point out that I shouldn't rely on things being in a
certain order when I SELECT * FROM table. I'm well aware of that, I
just generally have an aesthetic preference for a tabl
Karsten Hilbert wrote:
Craig, what kind of "events" are you thinking about? Triggers are
already pieces of code that run upon "certain events", namely insert,
update or delete events. What others do you have in mind?
That's a good point, actually. I can't think of much you can't do with a
tri
On Feb 3, 2009, at 11:55 PM, Guy Rouillier wrote:
Craig Ringer wrote:
An internal job scheduler with the ability to fire jobs on certain
events as well as on a fixed schedule could be particularly handy
in conjunction with true stored procedures that could explicitly
manage transactions.
Gregory Stark wrote:
> Steve Crawford writes:
>
3. Date handling
Sometimes I've got data with invalid dates and it would be great if it
could replace all the bad ones with, say "-00-00".
>> Oh dear $DEITY, no.
>
> I think it would be best if we limited ourselves rig
> > Craig, what kind of "events" are you thinking about? Triggers are
> > already pieces of code that run upon "certain events", namely insert,
> > update or delete events. What others do you have in mind?
>
> That's a good point, actually. I can't think of much you can't do with a
> trigger
On Wed, 2009-02-04 at 02:39 +, Greg Stark wrote:
> On Tue, Feb 3, 2009 at 10:06 PM, Simon Riggs wrote:
> >
> > On Tue, 2009-02-03 at 15:03 -0500, Chris Mayfield wrote:
> >
> >> 1. Having to rewrite entire tables out to disk the first time I scan
> >> them, for example:
> >>
> >> CREATE TABLE
On Wed, 2009-02-04 at 03:00 +, Greg Stark wrote:
> We already have autovacuum, which runs VACUUM and ANALYZE to a set
> > schedule. We could have kept that outside core, but didn't.
> >
> > It's not too big a stretch to imagine we could redesign autovacuum
> as a
> > GP scheduler, with autovac
On Tue, Feb 3, 2009 at 10:09 PM, Craig Ringer
wrote:
> Guy Rouillier wrote:
>>
>> Craig Ringer wrote:
>>>
>>> An internal job scheduler with the ability to fire jobs on certain events
>>> as well as on a fixed schedule could be particularly handy in conjunction
>>> with true stored procedures that
Guy Rouillier wrote:
Craig Ringer wrote:
An internal job scheduler with the ability to fire jobs on certain
events as well as on a fixed schedule could be particularly handy in
conjunction with true stored procedures that could explicitly manage
transactions.
Craig, what kind of "events" are
Craig Ringer wrote:
An internal job scheduler with the ability to fire jobs on certain
events as well as on a fixed schedule could be particularly handy in
conjunction with true stored procedures that could explicitly manage
transactions.
Craig, what kind of "events" are you thinking about?
Guy Rouillier wrote:
And someone else might want to play that game inside PG ;).
In fact, given how extensible PG is in other ways, it's surprising there
hasn't been more call for it. Perhaps the fact there there's presently
no facility for stored procedures to easily manage transactions has
On Tue, Feb 3, 2009 at 8:58 PM, Guy Rouillier wrote:
> Greg Stark wrote:
>>
>> My only point was that this would be very different from Oracle-style
>> job scheduler implemented *inside* the database using
>> database-specific code and requiring database-specific code to
>> interact with the outsi
Greg Stark wrote:
My only point was that this would be very different from Oracle-style
job scheduler implemented *inside* the database using
database-specific code and requiring database-specific code to
interact with the outside world. That's just reimplementing the whole
world using the databa
On Tue, Feb 3, 2009 at 9:27 PM, Simon Riggs wrote:
>
> On Mon, 2009-02-02 at 22:48 +, Gregory Stark wrote:
>> Christopher Browne writes:
>>
>> > - Managing jobs (e.g. - "pgcron")
>>
>> A number of people have mentioned a job scheduler. I think a job scheduler
>> entirely inside Postgres would
On Tue, 3 Feb 2009, Jeremy Harris wrote:
As a further take on the auto-tuning others have mentioned,
how about some auto-indexing?
That's a significantly harder problem than auto-tuning.
http://it.toolbox.com/blogs/database-soup/finding-useless-indexes-28796 is
a good intro to a subset of th
On Tue, Feb 3, 2009 at 10:06 PM, Simon Riggs wrote:
>
> On Tue, 2009-02-03 at 15:03 -0500, Chris Mayfield wrote:
>
>> 1. Having to rewrite entire tables out to disk the first time I scan
>> them, for example:
>>
>> CREATE TABLE t1 AS ...; -- writes 100 GB to disk
>> CREATE INDEX i1 ON t1 ...; -- r
On Tue, Feb 3, 2009 at 7:04 PM, David Fetter wrote:
>
>> Notably, there's no indication of which lock wait queue the
>> ungranted locks are in. That means to find out what's blocking a
>> lock would require comparing every other lock to it and deciding
>> whether it conflicts.
>
> Interesting :)
Gregory Stark wrote:
So, what do people say? Is Postgres perfect in your world or does it do some
things which rub you the wrong way?
As a further take on the auto-tuning others have mentioned,
how about some auto-indexing?
- Jeremy
--
Sent via pgsql-general mailing list (pgsql-general@postgr
On Mon, Feb 2, 2009 at 5:48 PM, Gregory Stark wrote:
> Christopher Browne writes:
>
>> - Managing jobs (e.g. - "pgcron")
>
> A number of people have mentioned a job scheduler. I think a job scheduler
> entirely inside Postgres would be a terrible idea.
I think it's a terrible idea to put words i
On Tue, 2009-02-03 at 15:03 -0500, Chris Mayfield wrote:
> 1. Having to rewrite entire tables out to disk the first time I scan
> them, for example:
>
> CREATE TABLE t1 AS ...; -- writes 100 GB to disk
> CREATE INDEX i1 ON t1 ...; -- rewrites 100 GB to disk
>
> The main issue is setting the hi
On Tue, 3 Feb 2009, Greg Stark wrote:
Notably, there's no indication of which lock wait queue the ungranted
locks are in. That means to find out what's blocking a lock would
require comparing every other lock to it and deciding whether it
conflicts.
The tool I find myself wanting here would pa
On Mon, 2009-02-02 at 22:48 +, Gregory Stark wrote:
> Christopher Browne writes:
>
> > - Managing jobs (e.g. - "pgcron")
>
> A number of people have mentioned a job scheduler. I think a job scheduler
> entirely inside Postgres would be a terrible idea.
You probably should explain why you t
On Feb 3, 2009, at 12:41 PM, Peter Geoghegan wrote:
What about postgreSQL's inability to re-order columns?
Please don't point out that I shouldn't rely on things being in a
certain order when I SELECT * FROM table. I'm well aware of that, I
just generally have an aesthetic preference for a tab
What about postgreSQL's inability to re-order columns?
Please don't point out that I shouldn't rely on things being in a
certain order when I SELECT * FROM table. I'm well aware of that, I
just generally have an aesthetic preference for a table's columns
being in a certain order.
Regards,
Peter G
Here's a few more pet peeves. I'm not sure if any of these are known
bugs or just me being picky.
--Chris
--
1. Having to rewrite entire tables out to disk the first time I scan
them, for example:
CREATE TABLE t1 AS ...; -- writes 100 GB to d
On Tue, Feb 03, 2009 at 05:48:51PM +, Greg Stark wrote:
> On Thu, Jan 29, 2009 at 5:43 PM, David Fetter wrote:
> >>
> >> > * CTEs not yet integrated into the adjacency lists in pg_catalog,
> >> > etc.
> >>
> >> I'm not sure what you're referring to here either.
> >
> > The DAG structures in pg
On Thu, Jan 29, 2009 at 5:43 PM, David Fetter wrote:
>>
>> > * CTEs not yet integrated into the adjacency lists in pg_catalog,
>> > etc.
>>
>> I'm not sure what you're referring to here either.
>
> The DAG structures in pg_depend leap to mind. There's no view that
> shows the actual dependencies,
- COPY command does not support collation. It's such a pita to massage
huge files that have "," has a decimal separator.
copy with delimiter '###'
http://www.postgresql.org/docs/current/static/sql-copy.html
--
Postgresql & php tutorials
http://www.designmagick.com/
--
Sent via pgsql-ge
Gregory Stark wrote:
Christopher Browne writes:
- Managing jobs (e.g. - "pgcron")
A number of people have mentioned a job scheduler. I think a job scheduler
entirely inside Postgres would be a terrible idea.
PgFoundry already has a project called "Job Scheduler".
--
Guy Rouillier
--
Sent
You realise you just described the very project you saw me write a
presentation on today right?
:-p
On 2/2/09, Gregory Stark wrote:
> Christopher Browne writes:
>
>> - Managing jobs (e.g. - "pgcron")
>
> A number of people have mentioned a job scheduler. I think a job scheduler
> entirely insid
Christopher Browne writes:
> - Managing jobs (e.g. - "pgcron")
A number of people have mentioned a job scheduler. I think a job scheduler
entirely inside Postgres would be a terrible idea.
However a cron daemon which used Postgres as a storage backend would be very
cool. It could then provide S
> - EXPLAIN does not work with functions.
+1
and one more about explain - it would be great to have smth like:
EXPLAIN ANALYZE FULL - that would show details about the plan chosen
with detailed explanation and other plans considered.
It would reduce a few posts a week in style:
- 'why the query A
On Thu, Jan 29, 2009 at 8:16 AM, Gregory Stark wrote:
> So, what do people say? Is Postgres perfect in your world or does it do some
> things which rub you the wrong way?
Things I'd particularly like to have that aren't entirely on the map yet:
- In place upgrade
- Stored procedures that can man
Gregory Stark wrote:
I'm putting together a talk on "PostgreSQL Pet Peeves" for discussion at
FOSDEM 2009 this year. I have a pretty good idea what some them are of course,
but I would be interested to hear if people have any complaints from personal
experience. What would be most interesting is
On Feb 2, 8:23 pm, br...@momjian.us (Bruce Momjian) wrote:
> wstrzalka wrote:
> > * stat collector is really greedy by definition even when system is
> > idle, when you have really really many relations
>
> I think this will be fixed in 8.4.
>
That would by great news for "mine" cluster.
--
Sent
wstrzalka wrote:
> * stat collector is really greedy by definition even when system is
> idle, when you have really really many relations
I think this will be fixed in 8.4.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If yo
My short list is:
* in-place upgrade
* named parameters in SQL functions
* native jobs
* timestamptz that preserves original timezone (not offset but
political timezone like America/New_York)
* I hate: "select * from dblink(...) as WHY(I_NEED int4, TO_SPECIFY
int4, THIS text)"
* ability to c
Octavio Alvarez wrote:
> On Fri, 2009-01-30 at 15:32 -0500, Bruce Momjian wrote:
> > Octavio Alvarez wrote:
> > > On Thu, 2009-01-29 at 13:16 +, Gregory Stark wrote:
> > > > So, what do people say? Is Postgres perfect in your world or does
> > it
> > > > do some
> > > > things which rub you the
On Sat, 31 Jan 2009, Adam Rich wrote:
- lack of queryable high-water marks useful for tuning
What specific things would you consider important to track a high-water
mark for that aren't already there?
--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via p
On Sat, 31 Jan 2009, Reece Hart wrote:
* lack of auto-tuning or tuning tools (or perhaps my lack of awareness
of them?)
http://pgfoundry.org/projects/pgtune/ aims to provide a tool for 8.4,
that's working but still needs documentation and some loose ends cleaned
up. Its suggestions aren't g
> On Saturday 31 January 2009 8:47:28 pm Adam Rich wrote:
> > On Thu, 29 Jan 2009 13:16:17 +
> >
> > Gregory Stark wrote:
> > > So, what do people say? Is Postgres perfect in your world or does
> it
> > > do some things which rub you the wrong way?
> >
> > I see all the major ones have alrea
On Saturday 31 January 2009 8:47:28 pm Adam Rich wrote:
> On Thu, 29 Jan 2009 13:16:17 +
>
> Gregory Stark wrote:
> > So, what do people say? Is Postgres perfect in your world or does it
> > do some things which rub you the wrong way?
>
> I see all the major ones have already been mentioned, s
On Sat, 2009-01-31 at 15:54 -0800, Octavio Alvarez wrote:
> On Sat, 2009-01-31 at 23:36 +, Gregory Stark wrote:
> > Octavio Alvarez writes:
> >
> > What about a WHERE clause like
> >
> > WHERE P1 > P2
>
> You could either:
>
> (1) do "FROM grades AS g1 INNER JOIN grades AS g2 ON g1.P1 > g2
Grzegorz Jaśkiewicz wrote on 01.02.2009 13:13:
probably enabling triggers for views would be the only way to do it, me thinks.
I don't know how oracle guys got around it.
Oracle *does* have (INSTEAD OF) triggers on views.
(and "simple" views are automatically updateable anyway)
Regards
Thomas
> rules are very very very very rarely useful.
I wouldn't say that. There are many use cases where rules are
just the thing. Plus they have an added performance benefit
when dealing with multiple rows in a single statement.
> yes, in general - I wouldn't mind to see postgresql implement fully
rules are very very very very rarely useful.
yes, in general - I wouldn't mind to see postgresql implement fully
updatable views.
There's being a very long discussion about that on -hackers, and patch
was even in cvs-head for a bit, but got dropped.
probably enabling triggers for views would be the
>> - no ability to define triggers on views
>>
>
> maybe because you can't perform insert/delete/update on them ?
>
Actually I was thinking the value of triggers on views is precisely
to allow you to perform insert/delete/update on them.
I know you can do this with rules, but there are cases
On Sun, Feb 1, 2009 at 10:20 AM, Dean Rasheed wrote:
> - no ability to define triggers on views
>
maybe because you can't perform insert/delete/update on them ?
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.post
The only one I can see that hasn't already been mentioned
- no ability to define triggers on views
Dean.
_
Windows Live Messenger just got better .Video display pics, contact updates &
more.
http://www.download.live.com/messenge
On Thu, 29 Jan 2009 13:16:17 +
Gregory Stark wrote:
> So, what do people say? Is Postgres perfect in your world or does it
> do some things which rub you the wrong way?
I see all the major ones have already been mentioned, so here's some
minor ones.
- lack of system-level and DDL triggers
My two:
* lack of PK/unique indexes on inherited tables (workarounds possible
but annoying)
* lack of auto-tuning or tuning tools (or perhaps my lack of awareness
of them?)
-Reece
--
Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0
On Sat, 2009-01-31 at 23:36 +, Gregory Stark wrote:
> Octavio Alvarez writes:
>
> > A crosstab is not but a presentational transform of the data set. Any
> > information you would eventually need can be taken from the original
> > data source, one way or another. That's why dynamic-column cro
Octavio Alvarez writes:
> In any case, the results are the same as GROUPing BY from the data
> source.
> +-+-+
> | Assignment | Average |
> +-+-+
> | Assignment1 | 94.67 |
> | Assignment2 | 90.33 |
> | Assignment3 | 86.67 |
> +-+-
On Sat, 2009-01-31 at 18:32 +, Greg Stark wrote:
> On Sat, Jan 31, 2009 at 5:34 PM, Octavio Alvarez
> wrote:
> >
> > It doesn't really matter. Since crosstabs are just a presentational
> > variation to a query with aggregate functions and GROUP BY clauses,
>
>
> Why are crosstabs just a pres
On Sat, Jan 31, 2009 at 11:10 AM, rhubbell wrote:
> Thanks, using the same apt commands, try to find pg_config.
> (^;
It's easy:
/home/smarlowe$ pg_config
The program 'pg_config' is currently not installed. You can install
it by typing:
sudo apt-get install libpq-dev
bash: pg_config: command no
On 2009-01-30, Steve Crawford wrote:
>
>> You can however pull it from a -Fc backup with pg_restore. Just FYI.
>>
>> Joshua D. Drake
>>
>
> Or strip it from a pg_dump/pg_dumpall with sed. Or write your own
> function-dumper based on ideas gleaned from various notes/comments on
> the web (my a
On 2009-01-29, Steve Crawford wrote:
>
>>> 3. Date handling
>>> Sometimes I've got data with invalid dates and it would be great if it
>>> could replace all the bad ones with, say "-00-00".
>>>
-00-00 doesn't fit in a date column.
perhaps you could use null?
write a function tha
On Sat, Jan 31, 2009 at 5:34 PM, Octavio Alvarez
wrote:
>
> It doesn't really matter. Since crosstabs are just a presentational
> variation to a query with aggregate functions and GROUP BY clauses,
Why are crosstabs just a presentation issue any more than GROUP BY or ORDER BY?
--
greg
--
Sen
On Sat, Jan 31, 2009 at 6:10 PM, rhubbell wrote:
> Thanks, using the same apt commands, try to find pg_config
$ apt-file search bin/pg_config
libpq-dev: /usr/bin/pg_config
postgresql-server-dev-8.3: /usr/lib/postgresql/8.3/bin/pg_config
That is confusing actually.
However, the readme for DBD::P
On Sat, Jan 31, 2009 at 10:10:01AM -0800, rhubbell wrote:
> Thanks, using the same apt commands, try to find pg_config.
Well, those commands search package names and metadata (including
descriptions), and pg_config isn't mentioned so you won't find
anything. Given that pg_config matches the versi
Thanks, using the same apt commands, try to find pg_config.
(^;
On Sat, 31 Jan 2009 12:38:18 +
Roger Leigh wrote:
> On Fri, Jan 30, 2009 at 03:44:48PM -0800, rhubbell wrote:
> > On Fri, 30 Jan 2009 20:38:06 +
> > Gregory Stark wrote:
> >
> > >
> > > rhubbell writes:
> > >
> > > >
On Fri, 2009-01-30 at 14:25 +, Gregory Stark wrote:
> "Daniel Verite" writes:
>
> > Gregory Stark wrote:
> >
> >> Is it the hierarchical query ability you're looking for or pivot?
> >> The former we are actually getting in 8.4.
> >>
> >> AFAIK even in systems with pivot you still have to
On Sat, 31 Jan 2009 15:28:31 +0100, Martijn van Oosterhout wrote:
> Nicest would be ofcourse a niceness level, so that VACUUM slows itself
> down according to the amount of queries going on (to a minimum ofcourse).
Linux has IO priority support for this, see ionice. Starting with 2.6.28
the CFQ s
Gregory Stark wrote:
MS-Access SQL has a TRANSFORM clause that allows for crosstab queries without
the need to know in advance the number of columns:
http://msdn.microsoft.com/en-us/library/bb208956.aspx
That's puzzling. I wonder what they do about clients requesting info about the
results. Or
On Fri, Jan 30, 2009 at 02:43:13PM -0800, Ron Mayer wrote:
> I guess I'd still like some more convenient tuning of autovacuum (perhaps
> specifying X mbps disk I/O); but I'd say vacuum fell off my pet-peeve list
> around the 8.1 timeframe.
ah yes, that reminds me. If I know what my disk subsystem
On Fri, Jan 30, 2009 at 03:44:48PM -0800, rhubbell wrote:
> On Fri, 30 Jan 2009 20:38:06 +
> Gregory Stark wrote:
>
> >
> > rhubbell writes:
> >
> > > Nope, had to find it in another package called libpq-dev.
> > > That's on UbuntuHardy. Maybe it's a maintainer problem?
> > >
> > > What lo
rhubbell writes:
>> Installing a package for DBD::Pg or building it? The former would indeed be a
>> package bug.
>
> When I installed the package I did via CPAN so maybe this was my mistake.
> Not every CPAN package is packaged for debian so I often times don't bother
> checking if a perl module
1 - 100 of 184 matches
Mail list logo
