> I apologize that my server was down Monday/Tuesday, rendering the
> patches queue unavailable. I also apologize that my secondary MX was
> misconfigured, causing some email bounces. I think everything is fixed
> now.
Hi Bruce,
I was checking out the patches queue, and there seems to be a mi
Hi all,
I propose to add an internal function gettime() that transparently
returns the current system time, as a timestamptz with maximum
precision.
Calling gettime() would be a more elegant approach than calling
timeofday() and converting it to a timestamp, and avoids some of the
potential probl
On 5/18/05, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> O.k. then I misunderstood and apologize. I think the above is
> reasonable. I wouldn't think that the main developers would stop
> developing to create this system, nor would I want them to take time
> away from development to implement it.
>
On 5/18/05, Stephen Frost <[EMAIL PROTECTED]> wrote:
> * Brendan Jurd ([EMAIL PROTECTED]) wrote:
> > In the interests of putting my money where my mouth is, I would be
> > willing to enlist in the housekeeping effort for this hypothetical new
> > system.
>
> If
On 5/18/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> The Postgres project has been exceedingly successful while using email
> lists as the primary means of communication/organization. I for one
> am disinclined to tinker with such a fundamental aspect of the way that
> the community operates. If we
On 5/18/05, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
>
> The key requirement that has always come up is that the core developers
> wouldn't use anything web based, so the tracker would have to somehow tie
> into the mailing lists themselves ...
>
What's the basis of this objection to a web-ba
As someone who's been lurking on the postgres lists for quite some
time, and submitted one (minor) patch, I think the notion of an
"entry-level" task list for we beginners is fantastic.
And, I'm sure this has been asked and answered a billion times
already, but why *don't* we have a real bug track
Neil Conway wrote:
I would be OK with just ignoring this case, but on reflection I would
prefer removing the "-t schema.table" syntax. Removing the feature
resolves the quoting issue and also simplifies pg_dump's behavior. We
lose the ability to dump table t1 in schema s1 and table t2 in schema s2
Tom Lane wrote:
Brendan Jurd <[EMAIL PROTECTED]> writes:
Of course, it would be possible to create a shorthand version of the
function which expects (text, interval), and passes directly to
time_span($1, now(), $2).
This bothers me a bit. That essentially says that (text, interva
Kris Jurka wrote:
On Sat, 15 Jan 2005, Brendan Jurd wrote:
> SELECT time_span( 'minute', now(), interval '10:43:55' );
643
The timestamp argument to this version of the function seems completely
irrelevent.
Kris Jurka
I don't think so. As I pointed
I've got an idea for a new internal function. I'm more than willing to
code it myself, but I'd like to run it past the list and thrash out any
conceptual issues before I get too excited about writing a patch.
When dealing with time values, it's not unknown to want to see a
particular time span
Tom Lane wrote:
Brendan Jurd <[EMAIL PROTECTED]> writes:
ERROR: query-specified return row and actual function return row do not
match
With that in mind, I'd like to submit a request, that the verbosity of
this error message be increased to explain which ordinal column po
Originally posted in psql-general, submitted here as a prospective RFE:
When using a row-returning function (RETURNS SETOF record) in the FROM
clause of a query, you have to supply a column definition list. I was
recently attempting to use a row-returning function in a query and
received the fo
501 - 513 of 513 matches
Mail list logo