Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
My idea is to create a new SECURITY DEFINER function called
serial_nextval(), and use that for SERIAL defaults.
You haven't thought about this at all. Who will own that function?
Surely we don't want to create a new one for
I have read this thread and I agree with Magnus that we have both new
and experienced users, and we need something simple like SERIAL for new
users.
I agree that having SERIAL be a macro is probably less that useless ---
you can create SERIAL easily, but to remove a table you have to
understand
Bruce Momjian pgman@candle.pha.pa.us writes:
My idea is to create a new SECURITY DEFINER function called
serial_nextval(), and use that for SERIAL defaults.
You haven't thought about this at all. Who will own that function?
Surely we don't want to create a new one for every SERIAL column.
And
On Tue, May 02, 2006 at 07:45:13PM -0700, elein wrote:
On Tue, May 02, 2006 at 12:00:42PM -0500, Jim C. Nasby wrote:
On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote:
On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I think a big
On Wed, May 03, 2006 at 10:12:28AM -0500, Jim C. Nasby wrote:
On Tue, May 02, 2006 at 07:45:13PM -0700, elein wrote:
On Tue, May 02, 2006 at 12:00:42PM -0500, Jim C. Nasby wrote:
On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote:
On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane
On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote:
On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I think a big point that's being missed here is that SERIAL *is* trying
to be simple. If you need something more sophisticated or complex
On Tue, May 02, 2006 at 12:00:42PM -0500, Jim C. Nasby wrote:
On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote:
On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I think a big point that's being missed here is that SERIAL *is* trying
Bruno Wolff III [EMAIL PROTECTED] writes:
I suggested a long time ago that default expressions should always be
executed as the owner of the table. This got shot down, but I don't remember
if it was because people thought the idea was bad in itself or if it was
the work involved (which I
On Mon, May 01, 2006 at 10:29:12AM -0400, Tom Lane wrote:
A cheesy compromise would be to switch userid for default-evaluation
only if the expression contains any volatile functions. I find this
idea pretty ugly, but it would allow us to still behave per-spec
for CURRENT_USER while getting
[EMAIL PROTECTED] writes:
If the user is specifying the default expression, they can specify
SECURITY DEFINER themselves, yes?
Not unless they write a wrapper function to be a security definer
and call nextval().
regards, tom lane
---(end of
On Mon, May 01, 2006 at 11:18:13AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
If the user is specifying the default expression, they can specify
SECURITY DEFINER themselves, yes?
Not unless they write a wrapper function to be a security definer
and call nextval().
Ah. I was wondering
[EMAIL PROTECTED] writes:
Ah. I was wondering about that. When I saw the first poster tag
'SECURITY DEFINER' on the end of the expression I assumed it was
something that I didn't know you could do... :-)
No, he was inventing syntax that doesn't exist.
regards, tom lane
I went back to see if I could find the discussion about this in the past.
It was less than I thought. Most it was me posting with some feedback from
Rod Taylor. The thread started with the subject What user to defaults execute
as? on general, but I mutated the subject to setuid for defaults,
Bruno Wolff III [EMAIL PROTECTED] writes:
The summary is that I was suggesting that default expressions, triggers and
constraints should all run as the table owner instead of the invoker as
there was little use for them to need the access of the invoker, while there
was benefit in having them
On Sun, Apr 30, 2006 at 01:42:37PM +0300, Hannu Krosing wrote:
I do see the benefits with regard to simplified implementation, and
flexibility.
As a compromise, I could see either choice being correct. I don't
see either direction as being both user friendly and simple.
You can be
On Sun, Apr 30, 2006 at 11:45:14AM +0200, Svenne Krap wrote:
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
Jim C. Nasby wrote:
On Mon, May 01, 2006 at 11:25:33AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
Ah. I was wondering about that. When I saw the first poster tag
'SECURITY DEFINER' on the end of the expression I assumed it was
something that I didn't know you could do... :-)
No, he was
Jim C. Nasby [EMAIL PROTECTED] writes:
I think a big point that's being missed here is that SERIAL *is* trying
to be simple. If you need something more sophisticated or complex you
shouldn't be using SERIAL at all, you should be doing the stuff
yourself, by hand.
I agree with this point in
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, May 01, 2006 at 11:25:33AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
Ah. I was wondering about that. When I saw the first poster tag
'SECURITY DEFINER' on the end of the expression I assumed it was
something that I didn't know you could
Sure, but there's no reason that would couldn't allow that with a true
black-box SERIAL, either. In fact, you can do it today if you want,
just by creating a wrapper around nextval(pg_get_serial_sequence()).
Or just use lastval()
Chris
---(end of
On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I think a big point that's being missed here is that SERIAL *is* trying
to be simple. If you need something more sophisticated or complex you
shouldn't be using SERIAL at all, you should be
Tom Lane [EMAIL PROTECTED] writes:
One argument against it is that it'd break trying to log who-did-what
by the expedient of having a column default CURRENT_USER:
blame_me text default current_user
No reason there couldn't be a separate function that returns the _actual_ user
rather
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
One argument against it is that it'd break trying to log who-did-what
by the expedient of having a column default CURRENT_USER:
blame_me text default current_user
No reason there couldn't be a separate function that
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
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 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
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
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 column. The hacks involved with SERIAL seem to me
to be getting
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 same as making a sequence and then making a default
expression that uses the
On Sat, 2006-04-29 at 17:54 -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 column.
40 matches
Mail list logo
