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 ...
re
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
Bruce Momjian writes:
> Is this ready for application? It looks good to me. However, there is
> an "Open issues" section.
It would be more useful to implement the SQL standard for intervals first
instead of inventing more nonstandard formats for it.
>
>
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.
>
> -
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 re
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
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
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 imple
Patch removed from queue.
---
Manfred Koizar wrote:
> On Mon, 01 Sep 2003 08:46:09 -0400, Tom Lane <[EMAIL PROTECTED]>
> wrote:
> >[EMAIL PROTECTED] writes:
> >> it took 69 minutes to finish, 75% of this time was devoted to
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 queu
Tom Lane wrote:
> 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 appl
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, an
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 not
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 s
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:
> Resubmis
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 hour
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 a
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.
---
Manfred Koizar wrote:
> On Mon, 8 Sep 200
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 8
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-un
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 20
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 2003
Sean Chittenden wrote:
> > > > Um, why not make it an actual full blown security feature by
> > > > applying the following patch? This gives PostgreSQL real read
> > > > only transactions that users can't escape from. Notes about the
> > > > patch:
> > >
> > > Way nifty.
> > >
> > > I vote i
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 comme
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
+
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.
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 stateme
Bruce Momjian wrote:
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.
I just applied the attached patch to cvs head, and equivalent ones on
the 7.3 and 7.4 stable branches. I also attached the out
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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 sys
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
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:
> First installment. The attached exports FUNC_MAX_ARGS as a read-only GUC
> variable -- func_max_args. Comments?
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
as
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 th
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
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
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 user or is
requestd by a
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
> --- ../cvs/
I wonder if it wouldn't be easier to reorder the TupDesc->attrs[] array
according to an attphysid when filling the TupDesc structure, right
after a column was dropped/recreated (before any indexes/constraints are
recreated), so attnum remains, while storage changes.
Example:
before:
attnum attph
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 d
40 matches
Mail list logo
