I would have gotten this out sooner but I'm having trouble with our
infrastructure. Here's a link to a table of data I've started putting
together regarding XLOG_BLCKSZ and wal_buffers on a 4-way Opteron
system:
http://developer.osdl.org/markw/pgsql/xlog_blcksz.html
There are a couple of
How about we remove RELKIND_SPECIAL? It was there only to support
the XactLockTable hack, but we don't need that anymore.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---(end of broadcast)---
[EMAIL PROTECTED] wrote:
> On Sun, Apr 30, 2006 at 09:14:53AM -0700, Mark Dilger wrote:
>
>>Tom Lane wrote:
>>
>>>1. A serial column is a "black box" that you're not supposed to muck with
>>>the innards of. This philosophy leads to the proposal that we disallow
>>>modifying the column default exp
I strongly agree with #2. The case at hand is where someone wants
a serial column with different defaults (wraparound, min, max) than
the standard serial. To achieve this an alter sequence is all that
is necessary. If it were not possible to do this so simply, then
the user would have to do #2
On Sun, Apr 30, 2006 at 09:14:53AM -0700, Mark Dilger wrote:
> Tom Lane wrote:
> > 1. A serial column is a "black box" that you're not supposed to muck with
> > the innards of. This philosophy leads to the proposal that we disallow
> > modifying the column default expression of a serial column, an
Martijn van Oosterhout writes:
> On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
>> 2. Run setRuleCheckAsUser during rule load rather than rule store.
> FWIW, I think #2 is better also.
Actually, I'm sitting here realizing the problem is more complicated
than I thought :-(. The spanne
On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
> 2. Run setRuleCheckAsUser during rule load rather than rule store.
>
> #2 is a lot simpler, and would fix the problem for existing broken rules
> whereas #1 would not, so I'm kind of inclined to go with that. I doubt
> there'd be any mea
... because nowhere does it update the "checkAsUser" fields in the
view's query to be the OID of the new owner. This means that
permission checks about whether the view can access its underlying
tables will still be done as the old owner. An example:
regression=# create user u1;
CREATE ROLE
regr
Tom Lane wrote:
> 1. A serial column is a "black box" that you're not supposed to muck with
> the innards of. This philosophy leads to the proposal that we disallow
> modifying the column default expression of a serial column, and will
> ultimately lead to thoughts like trying to hide the associat
On Sun, Apr 30, 2006 at 12:28:50 +0200,
>
> Since a real stumbling block with the macro approach seems to be the
> granting of permissions maybe we should work on that problem. For
> example, making SERIAL be a macro that expands to:
>
> id integer default nextval(sequence) SECURITY DEFINER,
>
>
On Fri, 28 Apr 2006, Brandon Black wrote:
I dug around in CVS to have a look for this, and I did eventually find
it (well, I found the corresponding docs patch that removed the note
about not working for joins). I see it's in MAIN but not in
8_1_STABLE. Does that mean it's headed for 8.2.x whe
On Sun, Apr 30, 2006 at 11:06:05AM +0200, Magnus Hagander wrote:
> If it's not obvious yet :-P, I'd be in favour of having SERIAL as
> black-box as possible, and then just use manual CREATE SEQUENCE and
> DEFAULT nextval() for when you need a more advanced case. But that's as
> seen from a user per
On Sun, Apr 30, 2006 at 01:42:37PM +0300, Hannu Krosing wrote:
> Ühel kenal päeval, L, 2006-04-29 kell 19:41, kirjutas
> [EMAIL PROTECTED]:
> > On Sat, Apr 29, 2006 at 05:54:19PM -0400, Tom Lane wrote:
> > > In short, I think there's a reasonably good case to be made for losing the
> > > hidden dep
Martijn van Oosterhout wrote:
On Sun, Apr 30, 2006 at 12:50:23PM +0200, Thomas Hallgren wrote:
I'm writing a UDT that takes a varchar argument that represents the name
of a type. The caller may optionally qualify with a namespace, i.e.
"pg_catalog.varchar", or "public.address". Is there a c-fun
On Sun, Apr 30, 2006 at 12:50:23PM +0200, Thomas Hallgren wrote:
> I'm writing a UDT that takes a varchar argument that represents the name
> of a type. The caller may optionally qualify with a namespace, i.e.
> "pg_catalog.varchar", or "public.address". Is there a c-function
> somewhere that wi
I'm writing a UDT that takes a varchar argument that represents the name
of a type. The caller may optionally qualify with a namespace, i.e.
"pg_catalog.varchar", or "public.address". Is there a c-function
somewhere that will return the pg_type that corresponds to the name
(with respect to the
Ühel kenal päeval, L, 2006-04-29 kell 19:41, kirjutas
[EMAIL PROTECTED]:
> On Sat, Apr 29, 2006 at 05:54:19PM -0400, Tom Lane wrote:
> > In short, I think there's a reasonably good case to be made for losing the
> > hidden dependency and re-adopting the viewpoint that saying SERIAL is
> > *exactly*
Rod Taylor wrote:
If SERIAL is going to be kept long term, then it should be the macro
version so it doesn't appear too duplicated.
I concur with this. But to really break out from the current middle ground, you must
implement the IDENTITY and also document the SERIAL macro as deprecated.
Re
On Sat, Apr 29, 2006 at 05:54:19PM -0400, Tom Lane wrote:
> In some recent activity on the patches list about responding to bug #2073,
> http://archives.postgresql.org/pgsql-bugs/2005-11/msg00303.php
> we've been discussing various possible tweaks to the behavior of dropping
> or modifying a serial
Tom Lane wrote:
In short, I think there's a reasonably good case to be made for losing the
hidden dependency and re-adopting the viewpoint that saying SERIAL is
*exactly* the same as making a sequence and then making a default
expression that uses the sequence. Nothing behind the curtain.
I
On Sat, 2006-04-29 at 23:15 -0400, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Do both. Return SERIAL to being a macro and implement the SQL IDENTITY
> > construct as the black box version.
>
> Doesn't SQL IDENTITY have a number of properties that are significantly
> different fro
> We started with #2 and have been moving slowly towards #1,
> but I think there's a limit to how far we want to go in that
> direction. A black box approach isn't especially
> user-friendly in my opinion; it's not solving any problems,
> it's just refusing to deal with the implications of ALT
Rod Taylor <[EMAIL PROTECTED]> writes:
> Do both. Return SERIAL to being a macro and implement the SQL IDENTITY
> construct as the black box version.
Doesn't SQL IDENTITY have a number of properties that are significantly
different from serial/nextval? I wasn't really volunteering to
implement a
FYI, 8.2 will have this and more based on this applied patch:
Add INET/CIDR operators: and, or, not, plus int8, minus int8, and inet
minus inet.
Stephen R. van den Berg
---
Patrick
24 matches
Mail list logo
