Hello,
Hopefully this hasn't been answered already. I attempted to do full
due-diligence on it, and could find no answer anywhere.
Basically my problem is that my server has both python 2.3 and python
2.4 installed (strange but unavoidable reasons behind this), and it
appears that my
What is the reasoning behind having two different implementations of the
datetime types, with slightly different behavior? Do we intend to keep
supporting both FP- and integer-based datetimes indefinitely?
Clearly, there are some costs associated with maintaining two different
implementations:
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: 05/05/07, 03:00:25
Subject: [HACKERS] New idea for patch tracking
As for #3, again, I don't want us to take on a burdensome patch tracking
process that is
roger wrote:
Where can I configure which version (or path) that postgres will use?
It uses whatever python program it can find first in the path. If
your observation is different, please show the relevant output from
configure or config.log.
--
Peter Eisentraut
Neil Conway wrote:
Notably, the FP datetime code doesn't depend on having a
functional int64 type, but in 2007, are there really any platforms we
care about that don't have such a type?
That is really the only question, AFAIR. The integer datetimes
implementation on a 32-bit type would have
Dave Page wrote:
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: 05/05/07, 03:00:25
Subject: [HACKERS] New idea for patch tracking
As for #3, again, I don't want us to take on a burdensome patch
Bruce Momjian wrote:
Dave Page wrote:
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: 05/05/07, 03:00:25
Subject: [HACKERS] New idea for patch tracking
As for #3, again, I don't want us to take on a
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Dave Page wrote:
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: 05/05/07, 03:00:25
Subject: [HACKERS] New idea for patch tracking
As for #3,
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Dave Page wrote:
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: 05/05/07, 03:00:25
Subject: [HACKERS] New idea for patch tracking
As
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Dave Page wrote:
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: 05/05/07, 03:00:25
Subject:
Bruce Momjian wrote:
Dave Page wrote:
Barring a few trivial details, that sounds almost identical to what I
proposed.
Well, Andrew says everyone he talks to doesn't want it. They want a
more comprehensive solution that goes from bug to patch.
Dave can speak for his own views, but I think
Peter Eisentraut wrote:
Neil Conway wrote:
Notably, the FP datetime code doesn't depend on having a
functional int64 type, but in 2007, are there really any platforms we
care about that don't have such a type?
That is really the only question, AFAIR. The integer datetimes
implementation on
On May 5, 1:34 am, [EMAIL PROTECTED] (Peter Eisentraut) wrote:
roger wrote:
Where can I configure which version (or path) that postgres will use?
It uses whatever python program it can find first in the path. If
your observation is different, please show the relevant output from
configure
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Dave Page wrote:
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: 05/05/07, 03:00:25
People aren't willing to hel pme in even a simple task of maintaining
an
8.3 patches status page, so why would they want to help with something
larger. I am not going to make my job harder only to find out no one
wants to help.
I thought about volunteering to do this, but:
1. I am a little
roger wrote:
So, any ideas on how I can get plpython.so to use Python 2.4?
You'll have to rebuild the whole thing.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
If you're saying we don't currently warn if a revoke leaves the
priviledges in-tact for the right and target, I'm not sure you can
currently get in a state where it'd be possible to run
Alvaro Herrera wrote:
I noticed that conversion_procs is sadly single-tasked to build. I
am wondering if it would be acceptable to rework the Makefile.shlib
to have an option to allow building multiple libs, by creating a rule
to collect libraries to build, and have each conversion_proc
I would like to add one point:
Bruce Momjian wrote:
Patch committers check several things before applying a patch:
1) Follows the SQL standard or community agreed-upon behavior
2) Style merges seamlessly into the surrounding code
3) Written as simply and efficiently as possible
4) Uses
OK, item modified to:
liPasses all regression tests, and if needed, adds new
ones/li
---
Zdenek Kotala wrote:
I would like to add one point:
Bruce Momjian wrote:
Patch committers check several
The current TODO list has:
Dependency Checking
===
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available
Nathan Buchanan [EMAIL PROTECTED] writes:
I had the idea of taking the Fourier transform of the waveform and storing
the waveform internally that way to reduce storage requirements.
Aside from what Steve said: The Fourier transform in itself doesn't
reduce data size --- it's N points in, N
Bruce Momjian wrote:
The current TODO list has:
Dependency Checking
===
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are
As promised I added a Patch Status site to the wiki:
http://developer.postgresql.org/index.php/Todo:PatchStatus
It contains all the patches tom mentioned in his recent patch queue
triage mail with references to the patches (either on the queue or in
the archives) as well as the author and the
There is now a link to it at the top of the patch queue web site.
---
Stefan Kaltenbrunner wrote:
As promised I added a Patch Status site to the wiki:
http://developer.postgresql.org/index.php/Todo:PatchStatus
It
In connection with completing David Fetter's array of composites patch,
I am looking at doing some better name mangling for array types as
recently discussed. What I'm thinking of is prepending one or more
underscores to the type name up to some limit (NAMEDATALEN / 2 ?) and if
necessary
Peter Eisentraut [EMAIL PROTECTED] writes:
Neil Conway wrote:
Notably, the FP datetime code doesn't depend on having a
functional int64 type, but in 2007, are there really any platforms we
care about that don't have such a type?
That is really the only question, AFAIR.
We've so far managed
I wrote:
In connection with completing David Fetter's array of composites
patch, I am looking at doing some better name mangling for array types
as recently discussed. What I'm thinking of is prepending one or more
underscores to the type name up to some limit (NAMEDATALEN / 2 ?) and
if
Andrew Dunstan [EMAIL PROTECTED] writes:
In connection with completing David Fetter's array of composites patch,
I am looking at doing some better name mangling for array types as
recently discussed. What I'm thinking of is prepending one or more
underscores to the type name up to some
On 5/5/07, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
As promised I added a Patch Status site to the wiki:
http://developer.postgresql.org/index.php/Todo:PatchStatus
The original autor of the temp_tablespace GUC patch is Albert Cervera
Areny albertca ( at ) hotpop ( dot ) com
Bruce Momjian [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
The current TODO list has:
Dependency Checking
===
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
In connection with completing David Fetter's array of composites patch,
I am looking at doing some better name mangling for array types as
recently discussed. What I'm thinking of is prepending one or more
underscores to the type
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
We've so far managed to avoid having any hard dependency on a working
int64 type, but this would certainly be one. I don't really think the
code-size-reduction argument is strong enough to justify that.
What benefit do we get from avoiding
I removed the cardinality item and marked the others as done:
* -Flush cached query plans when the dependent objects change or
when new ANALYZE statistics are available
* -Track dependencies in function bodies and recompile/invalidate
* -Invalidate prepared
Jaime Casanova wrote:
On 5/5/07, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
As promised I added a Patch Status site to the wiki:
http://developer.postgresql.org/index.php/Todo:PatchStatus
The original autor of the temp_tablespace GUC patch is Albert Cervera
Areny albertca ( at ) hotpop
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 05/05/07, 11:06:37
Subject: Re: [HACKERS] New idea for patch tracking
snip tracker outline
Barring a few trivial details, that sounds almost identical to what I
proposed.
Neil Conway wrote:
So, are there any corresponding benefits to providing both FP and
integer datetimes? AFAIK the following differences in user-visible
behavior exist:
There should be also problem with floating point implementation on
client and server side. For example if somebody use
What is the approved way to iterate over a relation's attributes? I see
that lsyscache.c::get_relnatts() is marked NOT_USED and has been for
nearly seven years. Maybe it's time to remove that code ;-)
cheers
andrew
---(end of broadcast)---
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
makeArrayTypeName and users thereof. Or are you going to extend pg_type
to have a direct link?
I am going to change makeArrayTypeName() to do the mangling. Its users
will need to pass in a namespace as well as a typename so it can do
Andrew Dunstan [EMAIL PROTECTED] writes:
What is the approved way to iterate over a relation's attributes?
Most places scan through the relation's tuple descriptor, rather
than expending multiple catalog lookups in pg_attribute.
regards, tom lane
Andrew Dunstan [EMAIL PROTECTED] writes:
Actually, looking back in the email history I see Tom suggested this,
which I'll try instead:
prepend _, truncate to less than 64 bytes if necessary,
then substitute numbers at the end if needed to get something unique.
Your idea of multiple
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
makeArrayTypeName and users thereof. Or are you going to extend pg_type
to have a direct link?
I am going to change makeArrayTypeName() to do the mangling. Its users
will need to pass in a
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
What is the approved way to iterate over a relation's attributes?
Most places scan through the relation's tuple descriptor, rather
than expending multiple catalog lookups in pg_attribute.
Doesn't that require me
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
What is the approved way to iterate over a relation's attributes?
Most places scan through the relation's tuple descriptor, rather
than expending multiple catalog lookups in pg_attribute.
Zdenek Kotala wrote:
Neil Conway wrote:
So, are there any corresponding benefits to providing both FP and
integer datetimes? AFAIK the following differences in user-visible
behavior exist:
There should be also problem with floating point implementation on
client and server side.
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
-Neil
---(end of broadcast)---
TIP 7: You can help support the
Neil Conway wrote:
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
But in those cases, we assume the client and server have the same
configuration, right?
--
I have been talking with Theo some more about his recent problem with
bytea arguments and results (see recent discussion on -bugs and also
recent docs patch), what he needs is a way to have bytea (and possibly
other unknown types) passed as binary data to and from plperl. The
conversion
Bruce Momjian wrote:
Neil Conway wrote:
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
But in those cases, we assume the client and
Andrew Dunstan [EMAIL PROTECTED] writes:
After discussing some possibilities, we decided that maybe
the best approach would be to allow a custom GUC variable that would
specify a list of types to be passed in binary form with no conversion, e.g.
plperl.pass_as_binary = 'bytea, other-type'
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
After discussing some possibilities, we decided that maybe
the best approach would be to allow a custom GUC variable that would
specify a list of types to be passed in binary form with no conversion, e.g.
Let me give you my approach to tracking. It might help set the stage
for moving forward. My goal has always been to foster discussion and
pull as many TODO items and patches from the discussion as possible (and
others do that as well by saying Please add to TODO or applying
patches).
I see the
On May 4, 2007, at 7:49 PM, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On a related note, it would also be *really* nice if we kept stats on
how many sorts or hashes had spilled to disk, perhaps along with how
much had spilled. Right now the only way to monitor that in a
production
On May 2, 2007, at 5:39 PM, Alvaro Herrera wrote:
The recently discovered autovacuum bug made me notice something
that is
possibly critical. The current autovacuum code makes an effort not to
leave workers in a starting state for too long, lest there be
failure
to timely tend all databases
On May 2, 2007, at 8:24 PM, JEAN-PIERRE PELLETIER wrote:
On the date variant, I wasn't sure how to handle intervals with
parts smaller than days:
floor, ceiling, round or error out
Hrm... I'm not sure what would be better there... I'm leaning towards
round (floor or ceil don't make much
55 matches
Mail list logo
