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
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
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 ALTER
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 from
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, 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
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.
Ü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* the
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
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 will
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
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 dependency
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
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
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,
Which
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 associated
... 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
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
Martijn van Oosterhout kleptog@svana.org 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
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, and will
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
[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 expression of a
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
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
24 matches
Mail list logo
