Joe Conway has an updated version of this he will be applying shortly.
Thanks.
Joe, please make sure you CC this person once your patch is applied.
---
Sergey N. Yatskevich wrote:
Hello!
bytea-test.cxx -- contains
Wang Mike wrote:
add clock_timestamp() and transaction_timestamp() function
see TODO list get more
-
diff -u -r ../cvs/pgsql/src/backend/utils/adt/timestamp.c
../pgsql/src/backend/utils/adt/timestamp.c
---
Bruce Momjian writes:
We have started 7.5 development so we can now work with you to complete
this item. Your question was what does statement_timestamp() show.
That has been discussed and it is a little tricky. The idea is that is
should be start of a single statement that arrives from the
Peter Eisentraut wrote:
Bruce Momjian writes:
We have started 7.5 development so we can now work with you to complete
this item. Your question was what does statement_timestamp() show.
That has been discussed and it is a little tricky. The idea is that is
should be start of a single
Bruce Momjian writes:
Yes, user-visible. They give additional current timestamp information.
transaction_timestamp() is the same as current_timestamp,
clock_timestamp is the same as gettimeofday(), and statement_timestamp
is a new one that shows statement start time.
And what would be the
Tom Lane writes:
One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.
You can determine these values by looking into the system catalogs.
I was intending to propose that we
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
(More generally, I wonder if AtEOXact_SPI oughtn't be fixed to emit
a WARNING if the SPI stack isn't empty, except in the error case.
Neglecting SPI_finish is analogous to a resource leak, and we have
code in place to warn about other sorts
Peter Eisentraut wrote:
Bruce Momjian writes:
Yes, user-visible. They give additional current timestamp information.
transaction_timestamp() is the same as current_timestamp,
clock_timestamp is the same as gettimeofday(), and statement_timestamp
is a new one that shows statement start
Peter Eisentraut wrote:
Tom Lane writes:
One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.
You can determine these values by looking into the system catalogs.
How,
Seems there are three GUC variables that are defined as Shows ...
while you can actually set them with SET.
This applied patch changes the wording from Show to Set.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If
Tom Lane wrote:
1. AFAIR, all the other at-end-of-xact routines that take a flag telling
them if it's commit or abort define the flag as isCommit. Having the
reverse convention for this one routine is confusing and a recipe for
errors, so please make it be isCommit too.
Done.
2. The initial
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Gavin Sherry wrote:
On Thu, 31 Jul
Is this ready for application? It looks good to me. However, there is
an Open issues section.
---
Ron Mayer wrote:
Short summary:
This patch allows ISO 8601 time intervals using the format
with time-unit
And another open issues email.
---
Ron Mayer wrote:
Tom wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Yes, but by the same token iso8601 isn't specific enough either.
ISO 8601 gives more
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Neil Conway wrote:
Attached is a patch
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Neil Conway wrote:
On Fri, 2003-10-10
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Christopher Kings-Lynne wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Neil Conway wrote:
This patch reduces
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Christopher Kings-Lynne wrote:
Just
Bruce Momjian [EMAIL PROTECTED] writes:
I will try to apply it within the next 48 hours.
My impression was that Neil didn't think this was ready yet:
As far as I know, the unique hash index code is functionally complete,
but don't add this to the patch queue (it is obviously for 7.5, anyway),
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I will try to apply it within the next 48 hours.
My impression was that Neil didn't think this was ready yet:
As far as I know, the unique hash index code is functionally complete,
but don't add this to the patch queue (it is
Patch removed.
---
Neil Conway wrote:
Attached is a patch that implements unique hash indexes. Regression
tests and docs have been updated (with the exception of
src/backend/access/hash/README).
This patches
Bruce Momjian [EMAIL PROTECTED] writes:
I will try to apply it within the next 48 hours.
This one's applied already, no?
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Tom Lane wrote:
One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.
I was intending to propose that we also export the following as
read-only variables:
* NAMEDATALEN
Joe Conway [EMAIL PROTECTED] writes:
name | name_data_len
setting| 63
short_desc | Shows the maximum identifier length
Defining the value as NAMEDATALEN-1 is reasonable (I was thinking of
suggesting that myself), but it seems like a recipe for confusion to
use name_data_len to refer
Bruce Momjian writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
This parameter ought to be called default_with_oids, to reflect the
actual effect.
Tom Lane wrote:
Perhaps the GUC variable name should be max_name_len or some such.
Also, should func_max_args and index_max_keys become max_func_args and
max_index_keys?
That sounds good to me:
-[ RECORD 3 ]--
name | max_func_args
setting| 32
Joe Conway [EMAIL PROTECTED] writes:
It will require an initdb -- should I hold off for other
pending changes also requiring initdb?
No, there's no particular reason to avoid initdbs during development
cycles. That's why we have catversion in the first place ...
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Manfred Koizar wrote:
On Mon, 01 Sep
Bruce Momjian [EMAIL PROTECTED] writes:
If qsort is to blame, then maybe this patch could help. It sorts
equal key values on item pointer. And if it doesn't help index
creation speed, at least the resulting index has better correlation.
I will try to apply it within the next 48 hours.
I
30 matches
Mail list logo
