Significant effort has been invested to make pg_dump output portable, and
I've not had any problems with it last time I tried it. Please explain
why you think it's "totally" non-portable.
Functions, indexes, operators, types, aggregates, users, groups,
databases, inheritance, clustering, col stat
Did you commit to 7.4.1 too Bruce?
Chris
Bruce Momjian wrote:
Patch applied. Thanks.
---
Jason Tishler wrote:
The attached patch enables contrib/cube to build cleanly under Cygwin
(again). Please consider this patch for
Hum, sorry to be late, but wasn't one of the supposed strenghts of
pg_dump supposed to be that you could take a dump and load it on a
different RDBMS? I haven't tried it so I don't know if it works, but
this patch takes out the ability to do that -- no one else will accept
WITH/WITHOUT OIDS, so th
Neil Conway writes:
> I'm really not sure we do: the SQL produced by pg_dump was totally
> non-portable before,
Significant effort has been invested to make pg_dump output portable, and
I've not had any problems with it last time I tried it. Please explain
why you think it's "totally" non-portab
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume this patch is to control this way of breaking out of a
> read-only transaction:
> [...]
> This seems like a valuable feature, as others have mentioned.
Why is this feature valuable?
A "read only user" is still able to easily DOS the server, con
Bruce Momjian wrote:
Peter Eisentraut wrote:
Joe Conway writes:
Any more thoughts on block_size (or page_size)?
It's always been some variant spelling of "block size", and I see no
reason to change the terminology.
Yes, that is from a coder's perspective, but from the user/admin
perspective, it see
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> He seems to have changed this too:
> - typedef uint32 IpcMemoryKey;
> + typedef size_t IpcMemoryKey;
> That really should be a key_t.
Yeah, I made it key_t in CVS tip. I'm just wondering what this could
avoid other than possibly a compile warning.
> > http://archives.postgresql.org/pgsql-patches/2003-07/msg00204.php
> > Sure sounds like you said READ ONLY xacts can't be used for security. :)
>
> Better read it again then.
Okay:
>> It's not intended to be a security measure, and I would strongly
>> resist any attempt to make it so along t
On Mon, Dec 01, 2003 at 06:08:06PM -0500, Tom Lane wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
> > On Mon, Dec 01, 2003 at 05:19:17PM -0500, Tom Lane wrote:
> >> After reviewing the proposed patch, I find it hard to believe that the
> >> patch would have fixed any such problem ---
>
> > It's
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We need a solution to this.
I'm really not sure we do: the SQL produced by pg_dump was totally
non-portable before, and it is slightly less portable now. ISTM that
you will almost always need to do some post-processing of pg_dump's
output to have any hop
Peter Eisentraut wrote:
> Alvaro Herrera writes:
>
> > On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote:
> >
> > > Neil Conway wrote:
> > > > This patch adds a new GUC var, "default_use_oids", which follows the
> > > > proposal for eventually deprecating OIDs on user tables that I pos
Sean Chittenden <[EMAIL PROTECTED]> writes:
> http://archives.postgresql.org/pgsql-patches/2003-07/msg00204.php
> Sure sounds like you said READ ONLY xacts can't be used for security. :)
Better read it again then.
> I think Tom's big objection is the abuse of the GUC system for
> maintaining thi
Patch applied. Thanks.
---
Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
>
> >
> >
> > Peter Eisentraut wrote:
> >
> >> Here is what I get:
> >>
> >> peter ~$ pg-install/bin/initdb pg-install/var/data
> >> ...
> >>
Patch applied to 7.4.X too.
---
Craig Boston wrote:
> Sorry about the cross-post -- I'm not 100% sure which list this should be sent
> to.
>
> I noticed in the 7.4 release that in contrib/pg_autovacuum, args->logfile is
>
Patch applied. Thanks.
---
Craig Boston wrote:
> Sorry about the cross-post -- I'm not 100% sure which list this should be sent
> to.
>
> I noticed in the 7.4 release that in contrib/pg_autovacuum, args->logfile is
> no
Patch applied. Thanks.
---
Jason Tishler wrote:
> The attached patch enables contrib/cube to build cleanly under Cygwin
> (again). Please consider this patch for the 7.4.1 branch (if there will
> be one) too.
>
> Thanks,
Sean Chittenden wrote:
> I think Tom's big objection is the abuse of the GUC system for
> maintaining this information. Having thought about this some, I think
> the GUC system is pretty well suited for this and that Tom's objection
> (correct me if I'm wrong here) is that GUC has a non-hierarchic
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Mon, Dec 01, 2003 at 05:19:17PM -0500, Tom Lane wrote:
>> After reviewing the proposed patch, I find it hard to believe that the
>> patch would have fixed any such problem ---
> It's not the key (key_t) that is the problem, but the size, which
> used to
Patch applied. Thanks.
---
Neil Conway wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Please use names for the replacement routines that are more clear
> > than "fooInternal". You can get away with that kind of name fo
> > Josh Berkus wrote:
> >> I thought that this was rejected thouroughly by Tom some months ago. He
> >> argued pretty strongly that READ ONLY transactions were *not* a security
> >> feature and that trying to make them one would work very poorly.
>
> > I remember something like that, but I tho
Peter Eisentraut wrote:
> Note that it is planned to unify users and groups into a general "role"
> entity, so this command is probably going to go away soon.
NP, at least the code is there for reuse.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Alvaro Herrera writes:
> On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote:
>
> > Neil Conway wrote:
> > > This patch adds a new GUC var, "default_use_oids", which follows the
> > > proposal for eventually deprecating OIDs on user tables that I posted
> > > earlier to pgsql-hackers. pg
Note that it is planned to unify users and groups into a general "role"
entity, so this command is probably going to go away soon.
Bruce Momjian writes:
> Nice:
>
> test=> create group test;
> CREATE GROUP
> test=> \dg
> List of database groups
>Group name | Group
On Mon, Dec 01, 2003 at 05:19:17PM -0500, Tom Lane wrote:
> Thomas Baden <[EMAIL PROTECTED]> writes:
> > Hi there. My install was failing the regression tests
> > due to a shared memory error.
>
> After reviewing the proposed patch, I find it hard to believe that the
> patch would have fixed any
On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote:
> Neil Conway wrote:
> > This patch adds a new GUC var, "default_use_oids", which follows the
> > proposal for eventually deprecating OIDs on user tables that I posted
> > earlier to pgsql-hackers. pg_dump now always specifies WITH OID
Patch applied. Thanks.
---
Christopher Kings-Lynne wrote:
> This makes help like this:
>
>\lo_export LOBOID FILE
>\lo_import FILE [COMMENT]
>\lo_list
>\lo_unlink LOBOIDlarge object operations
>
> Inst
Patch applied. Thanks.
---
Claudio Natoli wrote:
>
> If this is acceptable, I'll send a similar one for src/backend/Makefile
>
> Cheers,
> Claudio
>
>
> ---
> WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS:
> TH
Nice:
test=> create group test;
CREATE GROUP
test=> \dg
List of database groups
Group name | Group ID
+--
test | 100
(1 row)
test=> alter group test add user postgres;
Thomas Baden <[EMAIL PROTECTED]> writes:
> Hi there. My install was failing the regression tests
> due to a shared memory error.
After reviewing the proposed patch, I find it hard to believe that the
patch would have fixed any such problem --- even if key_t is 64 bits
on your system, the code sho
We have applied a variant of this to CVS. Thanks.
---
Thomas Baden wrote:
> Hi there. My install was failing the regression tests
> due to a shared memory error.
>
> I'm running Solaris 5.8, YASSP, and I am using the Sun
>
Peter Eisentraut wrote:
> Joe Conway writes:
>
> > Any more thoughts on block_size (or page_size)?
>
> It's always been some variant spelling of "block size", and I see no
> reason to change the terminology.
Yes, that is from a coder's perspective, but from the user/admin
perspective, it seems m
Just to confirm --- this was applied to 7.4 already.
---
Christopher Kings-Lynne wrote:
> Just noticed a bug in the previous version of the patch. Would fail
> against pre-7.3 postgres.
>
> Fixed in this new version. Jus
Patch applied. Thanks. Someone had already removed the assert() from
tab_complete.c, but not the #include .
---
Neil Conway wrote:
> This patch reduces some unsightly #ifdefs, and fixes two typos in
> comments in the psql
Patch applied. Thanks.
The CHECK part of this patch was already applied to 7.4.
---
Christopher Kings-Lynne wrote:
> Resubmission of patch (for 7.4).
>
> I fixed the problems I was having what I chatted to you Bruce, I'
Joe Conway writes:
> Any more thoughts on block_size (or page_size)?
It's always been some variant spelling of "block size", and I see no
reason to change the terminology.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: e
Bruce Momjian wrote:
Any more thoughts on block_size (or page_size)?
When I think of block size I think of disk blocks, and when I think of
pages I think of memory pages. Unfortunately, neither is a database
page.
I guess my point is that we have heap pages and index pages, but no one
calls them h
Updated patch applied. Thanks.
---
Neil Conway wrote:
> This patch adds a new GUC var, "default_use_oids", which follows the
> proposal for eventually deprecating OIDs on user tables that I posted
> earlier to pgsql-hacker
Patch applied. Thanks. That lock manager code really needed the cleanup.
---
Manfred Koizar wrote:
> On Mon, 8 Sep 2003 13:02:11 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >
> >Manfred, can I get a descript
Joe Conway wrote:
> Bruce Momjian wrote:
> > Joe Conway wrote:
> >>The description is a statement because the option is boolean, i.e. the
> >>statement "Datetimes are integer based" is either "true" or "false"
> >>("on" or "off", etc). How stongly do you feel about it? I don't think
> >>"integer
Bruce Momjian wrote:
Joe Conway wrote:
The description is a statement because the option is boolean, i.e. the
statement "Datetimes are integer based" is either "true" or "false"
("on" or "off", etc). How stongly do you feel about it? I don't think
"integer_datetime_storage" is accurate in any ca
Patch attached and applied. Thanks.
I adjusted the oid so prevent a duplicate, and adjusted the regression
test to remove comments on now non-existant functions.
I also tested the output and it looks good:
test=> select numeric_fac(10);
numeric_fac
---
Peter wrote:
>
> It would be more useful to implement the SQL standard for intervals first
> instead of inventing more nonstandard formats for it.
Much of the postgresql docs talks about ISO-8601 formats, so I would think
of the patch more as a standards-based improvemnt for the current interval
> -Original Message-
>
> Is this ready for application? It looks good to me. However, there is
> an "Open issues" section.
In my mind there were two categories of open issues
a) ones that are 100% backward (such as the comment about
outputting this format)
and
b) ones that are
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> I thought that this was rejected thouroughly by Tom some months ago. He
>> argued pretty strongly that READ ONLY transactions were *not* a security
>> feature and that trying to make them one would work very poorly.
> I remember
>> 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 point of that
Josh Berkus wrote:
> Bruce,
>
> > This seems like a valuable feature, as others have mentioned. However,
> > should it also prevent changes to default_transaction_read_only?
> >
> > What is the use case for this functionality?
>
> I thought that this was rejected thouroughly by Tom some months a
Joe Conway wrote:
> >>name | func_max_args
> >>name | index_max_keys
> > Should that be max_func_args and max_index_args? Seems more natural.
> > Should we spell out function? Probably. We already have
> > check_*function*_bodies.
>
> Agreed. Now:
> name | max_function_args
>
Bruce,
> This seems like a valuable feature, as others have mentioned. However,
> should it also prevent changes to default_transaction_read_only?
>
> What is the use case for this functionality?
I thought that this was rejected thouroughly by Tom some months ago. He
argued pretty strongly tha
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> There was just a discussion a few days ago about the page size for large
>> objects, for which the correct answer was "BLCKSZ/4" IIRC. Whether
>> people actually *should* care about the page size of large objects I
>> dunno, but th
Tom Lane writes:
> There was just a discussion a few days ago about the page size for large
> objects, for which the correct answer was "BLCKSZ/4" IIRC. Whether
> people actually *should* care about the page size of large objects I
> dunno, but the fact is some of them *do* care.
Maybe we should
Bruce Momjian wrote:
Joe Conway wrote:
name | block_size
OK. Should that be page_size? Not sure but block size sounds more like
a hardware setting. I know we call it BLCKSZ in our code but page size
seems more appropriate. Not sure.
Seems like block_size is more appropriate to me. Any oth
Manfred Koizar <[EMAIL PROTECTED]> writes:
> comparetup_index() compares two IndexTuples. The structure
> IndexTupleData consists basically of not much more than an ItemPointer,
> and the patch is not much more than adding a comparison of two
> ItemPointers. So how does the patch introduce a new
On Mon, 1 Dec 2003 00:02:54 -0500 (EST), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> >> And if it doesn't help index
>> >> creation speed, at least the resulting index has better correlation.
... which has been shown by the example in
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> This is a nonstarter, as is the previous proposal to have a single
>> function with an explicit parameter that selects the behavior. The
>> reason is that any such function would have to be treated as completely
>> non-optimizable.
Tom Lane wrote:
> In general, I do not like options that subtly change the behavior of
> long-established functions, anyway. Seems like a great recipe for
> breaking people's applications. I'm okay with adding new functions as
> per the already-agreed-to set of names (though like Peter I wish we
Tom Lane writes:
> This is a nonstarter, as is the previous proposal to have a single
> function with an explicit parameter that selects the behavior. The
> reason is that any such function would have to be treated as completely
> non-optimizable.
Why? We would just need to ensure that the mode
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> This is a nonstarter, as is the previous proposal to have a single
> >> function with an explicit parameter that selects the behavior. The
> >> reason is that any such function would have to be treated as comp
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is a nonstarter,
> Oh, I forgot about that. Peter seems only to want statement_timestamp
> and transaction_timestamp. Aren't those both stable if
> statement_timestamp is set from exec_simple_query?
Hm. If you restricted the o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It would be very useful if we had a parameter that controlled whether
> current_timestamp maps to statement_timestamp or to transaction_timestamp.
This is a nonstarter, as is the previous proposal to have a single
function with an explicit parameter t
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > It would be very useful if we had a parameter that controlled whether
> > current_timestamp maps to statement_timestamp or to transaction_timestamp.
>
> This is a nonstarter, as is the previous proposal to have a single
> function
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The goal was to give a unified API to the various time measurements:
> >
> > [clock|statement|transaction]_timestamp
>
> It would be very useful if we had a parameter that controlled whether
> current_timestamp maps to statement_timestamp
Peter Eisentraut wrote:
> 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.
OK, pa
Agreed.
---
Peter Eisentraut wrote:
> 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 appl
Joe Conway wrote:
> 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-
Patch already applied.
---
Christopher Kings-Lynne wrote:
> Just noticed a bug in the previous version of the patch. Would fail
> against pre-7.3 postgres.
>
> Fixed in this new version. Just discard the old.
>
> Chris
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I will try to apply it within the next 48 hours.
>
> This one's applied already, no?
Yes, sorry. Removed.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+
Bruce Momjian writes:
> The goal was to give a unified API to the various time measurements:
>
> [clock|statement|transaction]_timestamp
It would be very useful if we had a parameter that controlled whether
current_timestamp maps to statement_timestamp or to transaction_timestamp.
There see
67 matches
Mail list logo
