On Mon, Oct 31, 2011 at 5:23 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2 the presence of recovery.conf can and therefore should continue
to act as it does in 9.1.
This means that recovery.conf is renamed to
I have not tried the patch (yet), but Informix'sl dbacess would do about
the same - and it's something I really missed.
Jan
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Mon, Oct 31, 2011 at 12:54, Marcin Mańk marcin.m...@gmail.com wrote:
How about an option for psql to truncate too long columns to X characters ?
I would really want this in some form or another; for example, being
able to hide bytea values entirely, or set limits to how many
characters are
On 1 November 2011 00:14, Andrew Dunstan and...@dunslane.net wrote:
On 10/30/2011 10:00 PM, Christopher Browne wrote:
I don't think I wish it. We're telling our developers not to use select
*, and I don't think having select * except would change that policy,
beyond requiring us to waste
On Tue, Nov 1, 2011 at 00:18, Scott Mead sco...@openscg.com wrote:
On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander mag...@hagander.net
wrote:
Actually, for the future, it might be useful to have a state column,
On Tue, Nov 1, 2011 at 5:59 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Oct 31, 2011 at 5:23 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2 the presence of recovery.conf can and therefore should continue
On Tue, Nov 1, 2011 at 7:38 AM, Magnus Hagander mag...@hagander.net wrote:
If we are doing it, it might be useful to just call it query, so
that it is dead obvious to people that the definition changed..
Yeah. Otherwise, people who are parsing the hard-coded strings idle
and idle in
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you change a parameter that only has effect during recovery then
must get an error if it is changed during normal running.
I don't see why. If you're in normal running and someone changes a
parameter that is irrelevant
When a server fails, we need to promote a standby as quickly as possible.
Currently when we promote a standby to a primary we need to run a
shutdown checkpoint before users can begin write transactions, which
in many cases can take minutes.
The reason we run a shutdown checkpoint is to prevent
On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you change a parameter that only has effect during recovery then
must get an error if it is changed during normal running.
I don't see why. If
On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander mag...@hagander.net wrote:
Actually, for the future, it might be useful to have a state column,
that holds the idle/in transaction/running status, instead of the
tools
On Tue, Nov 1, 2011 at 13:19, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander mag...@hagander.net wrote:
Actually, for the future, it might be useful to have a state column,
On Tue, Nov 1, 2011 at 12:41 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Nov 1, 2011 at 13:19, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander mag...@hagander.net
On Sat, Oct 29, 2011 at 5:26 PM, Eric Ridge eeb...@gmail.com wrote:
Would y'all accept a patch that extended the SELECT * syntax to let
you list fields to exclude from the A_Star?
Quite regularly I'll be testing queries via psql and want to see all
the columns from a fairly wide table except
On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you change a parameter that only has effect during recovery then
must
On Tue, Nov 1, 2011 at 8:41 AM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Nov 1, 2011 at 13:19, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander mag...@hagander.net
Simon Riggs si...@2ndquadrant.com writes:
The reason we run a shutdown checkpoint is to prevent needing to
re-enter recovery if we crash after promotion.
That's *a* reason, it's not necessarily the only reason. This proposal
worries me, especially your blithe dismissal of the timeline issues;
Simon Riggs si...@2ndquadrant.com writes:
Why not leave it exactly as it is, and add a previous_query column?
That gives you exactly what you need without breaking anything.
That would cost twice as much shared memory for query strings, and twice
as much time to update the strings, for what
On Tue, Nov 1, 2011 at 1:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Why not leave it exactly as it is, and add a previous_query column?
That gives you exactly what you need without breaking anything.
That would cost twice as much shared memory for
On Tue, Nov 1, 2011 at 9:45 AM, Simon Riggs si...@2ndquadrant.com wrote:
Why do we have this log message then, if it is OK to ignore changes
that have no effect?
LOG: parameter shared_buffers cannot be changed without restarting the
server
I believe we're logging the fact that we were
On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Why not leave it exactly as it is, and add a previous_query column?
That gives you exactly what you need without breaking anything.
That would cost twice as much shared memory for
On Mon, Oct 31, 2011 at 23:37, Scott Mead sco...@openscg.com wrote:
So I wrote the attached patch, it just turns IDLE in transaction into:
IDLE in transaction\n: Previous: last query executed. After seeing
how quickly our dev's fixed the issue once they saw prepared statement XYZ,
Solving
On Tue, Nov 1, 2011 at 1:23 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 2:04 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 9:45 AM, Simon Riggs si...@2ndquadrant.com wrote:
Why do we have this log message then, if it is OK to ignore changes
that have no effect?
LOG: parameter shared_buffers cannot be changed without
On Tue, Nov 1, 2011 at 1:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
The reason we run a shutdown checkpoint is to prevent needing to
re-enter recovery if we crash after promotion.
That's *a* reason, it's not necessarily the only reason. This proposal
On 2011-11-01 21:13, Andrew Dunstan wrote:
Rename it please. current_query will just be wrong. I'd be inclined
just to call it query or query_string and leave it to the docs to
define the exact semantics.
I think query for a query that isn't ongoing would be just as wrong.
How about
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That would cost twice as much shared memory for query strings, and twice
as much time to update the strings, for what seems pretty marginal
value. I'm for just redefining the query
On Mon, Oct 31, 2011 at 20:59, Magnus Hagander mag...@hagander.net wrote:
On Mon, Oct 31, 2011 at 20:58, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
So once again I forgot about the fact that you can specify multiple
LDAP server in our ldapserver parameter
On Fri, Oct 28, 2011 at 20:58, Robert Haas robertmh...@gmail.com wrote:
I tried sprinkling a little branch-prediction magic on this code using
GCC's __builtin_expect(). That initially seemed to help, but once I
changed the BufferIsValid() test to !BufferIsInvalid() essentially all
of the
On Tue, Nov 1, 2011 at 10:47 AM, Marti Raudsepp ma...@juffo.org wrote:
On Fri, Oct 28, 2011 at 20:58, Robert Haas robertmh...@gmail.com wrote:
I tried sprinkling a little branch-prediction magic on this code using
GCC's __builtin_expect(). That initially seemed to help, but once I
changed the
2011/11/1 Marti Raudsepp ma...@juffo.org:
On Mon, Oct 31, 2011 at 23:37, Scott Mead sco...@openscg.com wrote:
So I wrote the attached patch, it just turns IDLE in transaction into:
IDLE in transaction\n: Previous: last query executed. After seeing
how quickly our dev's fixed the issue
On Tue, Nov 1, 2011 at 6:36 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/1/11 10:34 AM, Simon Riggs wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards compatibility entirely, and stop
2011/11/1 Eric Ridge eeb...@gmail.com:
On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
some other idea - but only for psql
we can define a special values, that ensure a some necessary
preexecution alchemy with entered query
\pset star_exclude_names col1,
Peter Eisentraut pete...@gmx.net writes:
Here is a finalized patch for this. The first hunk of the patch is the
documentation change, so you can see there how it's supposed to work.
Let me know what you think.
+1
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise,
2011/10/21 Robert Haas robertmh...@gmail.com:
On Fri, Oct 21, 2011 at 12:44 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I had checked my older implementation based on 8.4.x or 9.0.x that
includes all the features that I want to implement.
At least, it does not require so much different
Robert Haas wrote:
On Tue, Nov 1, 2011 at 2:49 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
It turns out there was only one place that expected a 1-1 mapping of
old
and new databases (file transfer), so I just modified that code to
allow
skipping a database
Robert Haas wrote:
On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
What I would prefer is to have the upgrade succeed, and just ignore
the existence of a postgres database in the new cluster. ?Maybe give
the user a notice and let them decide
Robert Haas wrote:
It turns out there was only one place that expected a 1-1 mapping of old
and new databases (file transfer), so I just modified that code to allow
skipping a database in the new cluster that didn't exist in the old
cluster.
Urp. ?But that means that if someone has
Bruce Momjian wrote:
What I would prefer is to have the upgrade succeed, and just ignore
the existence of a postgres database in the new cluster. Maybe give
the user a notice and let them decide whether they wish to take any
action. I understand that failing is probably less code, but
On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat r...@xzilla.net wrote:
On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards
On Tue, Nov 1, 2011 at 2:36 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
What I would prefer is to have the upgrade succeed, and just ignore
the existence of a postgres database in
Robert,
In most cases we either break backwards compatibility or require some
type of switch to turn on backwards compatibility for those who want
it. While the above plan tries to do one better, it leaves me feeling
that the thing I don't like about this is that it sounds like you are
On Tue, Nov 1, 2011 at 18:11, Scott Mead sco...@openscg.com wrote:
On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That would cost twice as much shared memory
On Tue, Nov 1, 2011 at 1:32 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I tried to summarize permission checks of DAC/MAC on several object classes
that are allowed to assign security label right now.
http://wiki.postgresql.org/index.php?title=SEPostgreSQL/Permissions
In most of checks,
On Tue, Nov 1, 2011 at 2:49 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
It turns out there was only one place that expected a 1-1 mapping of old
and new databases (file transfer), so I just modified that code to allow
skipping a database in the new cluster that didn't
On 11/1/11 10:34 AM, Simon Riggs wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards compatibility entirely, and stop supporting recovery.conf
as a trigger file at all.
Note that is
On Tue, Nov 1, 2011 at 1:53 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
What I would prefer is to have the upgrade succeed, and just ignore
the existence of a postgres database in the new cluster. Maybe give
the user a notice and let them decide whether they wish to take
2011/11/1 Eric Ridge eeb...@gmail.com:
On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
some other idea - but only for psql
we can define a special values, that ensure a some necessary
preexecution alchemy with entered query
\pset star_exclude_names col1,
On Tue, Nov 01, 2011 at 10:55:02AM -0400, Robert Haas wrote:
Well, the obvious problem is that we might end up spending a lot of
work on something that doesn't actually improve performance, or even
makes it worse, if our guesses about what's likely and unlikely turn
out to be wrong. If we can
On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Nov 1, 2011 at 18:11, Scott Mead sco...@openscg.com wrote:
On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 1, 2011 at 9:52 AM,
On Tue, Nov 1, 2011 at 18:40, Scott Mead sco...@openscg.com wrote:
On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Nov 1, 2011 at 18:11, Scott Mead sco...@openscg.com wrote:
On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert
On Tue, Nov 1, 2011 at 2:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat r...@xzilla.net wrote:
On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we
On Tue, Nov 1, 2011 at 12:03 PM, Stephen Frost sfr...@snowman.net wrote:
Note- I haven't looked at the * production or tried to do anything w/ gram.y
to
support this yet, but it's a heck of a lot shorter..
My original thought, that I probably didn't explain too clearly, was
to make the
On Tue, Nov 1, 2011 at 9:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 10:47 AM, Marti Raudsepp ma...@juffo.org wrote:
On Fri, Oct 28, 2011 at 20:58, Robert Haas robertmh...@gmail.com wrote:
I tried sprinkling a little branch-prediction magic on this code using
GCC's
On Tue, Nov 1, 2011 at 1:20 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Nov 1, 2011 at 18:11, Scott Mead sco...@openscg.com wrote:
On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 1, 2011 at 9:52 AM, Tom
On 11/01/2011 09:52 AM, Tom Lane wrote:
Simon Riggssi...@2ndquadrant.com writes:
Why not leave it exactly as it is, and add a previous_query column?
That gives you exactly what you need without breaking anything.
That would cost twice as much shared memory for query strings, and twice
as
On Mon, Oct 31, 2011 at 09:14:48AM -0400, Andrew Dunstan wrote:
The fact is that if you have 100 columns and want 95 of them, it's
very tedious to have to specify them all, especially for ad hoc
queries where the house SQL standards really don't matter that much.
It's made more tedious by the
Eric Ridge eeb...@gmail.com writes:
My original thought, that I probably didn't explain too clearly, was
to make the EXCLUDING (...) bit a modifier to the A_Star node. The
idea being that you could write * EXCLUDING (...) anywhere you can
currently write *.
I can think of a number of places
On Nov 1, 2011, at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I can think of a number of places where you can write * where I'm
pretty sure we *don't* want this. It should be restricted to top-level
entries in SELECT targetlists, IMO.
Yes. That is the exact conclusion I've come to.
On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards compatibility entirely, and stop supporting recovery.conf
as a trigger
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards compatibility entirely, and stop supporting recovery.conf
as a trigger file at all.
Note that is exactly what I have suggested when using
On Tue, Nov 1, 2011 at 10:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 1, 2011 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That would cost twice as much shared memory for query strings, and twice
as much time to update the strings, for
On Tue, Nov 01, 2011 at 10:13:52AM -0400, Andrew Dunstan wrote:
On 11/01/2011 09:52 AM, Tom Lane wrote:
Simon Riggssi...@2ndquadrant.com writes:
Why not leave it exactly as it is, and add a previous_query column?
That gives you exactly what you need without breaking anything.
That would
2011/11/1 Eric Ridge eeb...@gmail.com:
On Tue, Nov 1, 2011 at 1:33 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
COPY (SELECT * EXCLUDING (a, b, c) FROM big query) TO 'somefile.csv' WITH
CSV;
sorry, I don't accept it. I am able to understand your request for
adhoc queries. But not for
2011/11/1 Robert Haas robertmh...@gmail.com:
On Tue, Nov 1, 2011 at 1:32 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I tried to summarize permission checks of DAC/MAC on several object classes
that are allowed to assign security label right now.
On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
some other idea - but only for psql
we can define a special values, that ensure a some necessary
preexecution alchemy with entered query
\pset star_exclude_names col1, col2, col3
\pset star_exclude_types xml,
On Thu, Oct 6, 2011 at 12:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
+1. However, if that's the route we're traveling down, I think we had
better go ahead and remove the one remaining = operator from hstore
in 9.2:
Fair enough.
So, I tried to work
I'm working on fixing the stale-toast-pointer problem discussed in
http://archives.postgresql.org/message-id/2348.1319591...@sss.pgh.pa.us
In that thread, it was pointed out that it's unsafe to fetch a toasted
value unless we are advertising a MyProc-xmin that's old enough to
prevent removal of
On Tue, Nov 1, 2011 at 1:33 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
COPY (SELECT * EXCLUDING (a, b, c) FROM big query) TO 'somefile.csv' WITH
CSV;
sorry, I don't accept it. I am able to understand your request for
adhoc queries. But not for COPY.
I apologize if that example was
Hackers,
Is there a reason why INTERVAL 'infinity' is not implemented? That is,
an interval which is larger than all defined intervals, and which added
to any timestamp turns it into 'infinity'.
Or is it just Round TUITs?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent
On 11/1/11 12:29 PM, Robert Treat wrote:
Starting in 9.2, you should use pg_ctl standby to launch your
database for normal operations and/or in cases where you are writing
init scripts to control your production databases. For backwards
compatibility, if you require the old behavior of using a
* Marti Raudsepp (ma...@juffo.org) wrote:
Unfortunately it's far less efficient. Fields would be truncated in
psql, so full values are still detoasted and transmitted over the
network.
I'm thinking that we're not too worried about performance of ad-hoc
psql queries..? At least, for the
On Wed, Oct 19, 2011 at 3:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Oct 19, 2011 at 3:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Oct 19, 2011 at 9:45 PM, Robert Haas robertmh...@gmail.com wrote:
I don't really see any reason to break the monitoring view just
because
On Tue, Nov 1, 2011 at 9:11 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/1/11 12:29 PM, Robert Treat wrote:
Starting in 9.2, you should use pg_ctl standby to launch your
database for normal operations and/or in cases where you are writing
init scripts to control your production databases.
looks like the v3 patch re-introduces the pg_subtrans issue...
On Tue, Nov 1, 2011 at 9:33 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Oct 27, 2011 at 4:25 PM, Simon Riggs si...@2ndquadrant.com
wrote:
StartupMultiXact() didn't need changing, I thought, but I will review
further.
Eric B. Ridge eeb...@gmail.com writes:
However, why is
select table.* foo from table
allowed? What does that even mean?
Doesn't mean anything, I think --- the SQL standard seems to exclude it.
It's fairly hard to prevent it at the grammar level, since we regard
foo.* as a type of
On Nov 1, 2011, at 11:19 AM, Robert Haas wrote:
Fair enough.
So, I tried to work up a patch for this, but I'm actually a bit
confused about what needs to be done here. I'll attach what I've got
so far as a starting point for discussion.
Looks reasonable, if verbose. (Yes, the extension
Josh Berkus wrote:
Hackers,
Is there a reason why INTERVAL 'infinity' is not implemented? That is,
an interval which is larger than all defined intervals, and which added
to any timestamp turns it into 'infinity'.
Or is it just Round TUITs?
Probably the latter.
There is even a function
79 matches
Mail list logo
