Hello,
i searched around about privileges for functions, but it seems,
that there is nothing available in the 7.2.x series.
So my question: Is it possible to execute a function (in this case
a C function) with permissions of the function creater instead
of the user who's actual using function?
Patents are as much designed to confuse and dissuade someone from using
something as they are to patent something. Reading a patent is often
harder than killing the nearest chicken, strewing it's entrails allover
the yard, and then trying to make some sense of it.
Justin Clift wrote:
Hannu
On Wed, 2002-04-10 at 21:55, Justin Clift wrote:
Hannu Krosing wrote:
On Wed, 2002-04-10 at 16:32, Justin Clift wrote:
Hi everyone,
This is Prof. Bayer's response to the question is it alright to use
UB-Tree's in Open Source projects?.
Have you found out _what_ exaclty is
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
That means that
a lot of low-level places *do* need to know about the dropped-column
convention, else they can't make any sense of tuple layouts.
Why ? As you already mentioned, there were not that many places
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but
I think he made a representational mistake by trying to change the
attnums of dropped columns to be negative values.
Negative attnums had 2 advantages
Hiroshi Inoue wrote:
Why ? As you already mentioned, there were not that many places
to be changed.
Well what's changed since then ?
Here is an old email from me that outlines the idea of having a
physical/logical attribute numbering system, and the advantages.
I already
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hi all,
I got these odd messages while doing a vacuum in 7.1.3 0 - any idea what
they mean? I assume it's not fatal as they're just notices, but I've never
had them before and haven't had them since.
NOTICE: RegisterSharedInvalid: SI buffer overflow
NOTICE: InvalidateSharedInvalid: cache
On Thu, 11 Apr 2002, Christopher Kings-Lynne wrote:
Hi all,
I got these odd messages while doing a vacuum in 7.1.3 0 - any idea what
they mean? I assume it's not fatal as they're just notices, but I've never
had them before and haven't had them since.
NOTICE: RegisterSharedInvalid: SI
Neil Conway [EMAIL PROTECTED] writes:
Unfortunately, bison isn't very
helpful: it doesn't provide line-numbers when it warns me about
the # of conflicts.
Run bison with -v switch (thus, bison -y -d -v gram.y) and look at
the y.output file it produces. More detail than you really wanted ;-)
Gavin Sherry [EMAIL PROTECTED] writes:
NOTICE: RegisterSharedInvalid: SI buffer overflow
NOTICE: InvalidateSharedInvalid: cache state reset
To fix this increase shared_buffers.
AFAIK shared_buffers has no direct effect on the rate of SI overruns.
I suppose it might have an indirect effect
I don't see in this patch that you've added your new keywords to any of the
lists of reserved words towards the bottom of gram.y. Have a look down and
see the lists. You need to add the keywords to the first list in the file
that doesn't give a shift/reduce error. (ie. make the words the least
In fact, my grammar currently has an obscene
20 shift/reduce and 4 reduce/reduce conflicts!
A shift/reduce conflict, IIRC, usually indicates a situation where
the grammar is unambiguous but may be inefficient. Eliminating them
is nice, but not critical.
A R/R conflict, in contrast, is a
Out of interest, since the FE/BE protocol apprently doesn't support prepared
statements (bound variables), what does this patch actually _do_?
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Neil Conway
Sent: Thursday, 11 April 2002 9:29 AM
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Also, Tom (or anyone): in regards to your previous email,
should I just go
back to using opt_symmetry to shorten the number of productions, since I
have to make them reserved words anyway?
Might as well. No point in writing more
On Thu, 11 Apr 2002 10:54:14 +0800
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Out of interest, since the FE/BE protocol apprently doesn't support prepared
statements (bound variables), what does this patch actually _do_?
It implements preparable statements, by adding 3 new SQL
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Since it's really just two ways of writing the same thing, wouldn't bison
just produce the exact same C code? I'll rewrite it anyway for elegance,
but just wondering...
The emitted code might or might not be the same --- but duplicate or
Bear Giles [EMAIL PROTECTED] writes:
As an aside, is there any reason to treat TEMP and TEMPORARY as two
separate identifiers?
Yes: if the lexer folds them together then unreserved_keyword can't
regenerate the equivalent name properly. (Possibly this could be fixed
by making the lexer pass
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Why ? As you already mentioned, there were not that many places
to be changed.
Well what's changed since then ?
Here is an old email from me that outlines the idea of having a
physical/logical attribute numbering system, and the
Hiroshi Inoue wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me seems only a waste of time.
Christopher Kings-Lynne wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me seems only a
Bear Giles [EMAIL PROTECTED] writes:
Yes: if the lexer folds them together then unreserved_keyword can't
regenerate the equivalent name properly.
But if they're synonyms, is that necessary?
If I say
create table foo (temp int);
I will be annoyed if the system decides that the column
Christopher Kings-Lynne wrote:
Actually, what we need to do to reclaim space is to enable table
recreation without the column, now that we have relfilenode for file
renaming. It isn't hard to do, but no one has focused on it. I want to
focus on it, but have not had the time, obviously,
Christopher Kings-Lynne wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me seems only
Hiroshi Inoue wrote:
It seems to me that whatever we do
will require some kind of client breakage.
Physical/logical attnum approach was mainly to not break
clients. I implemented it on trial but the implementation
was hard to maintain unfortunately. It's pretty difficult
to decide
Is anyone feeling we have the 7.3 release nearing? I certainly am not.
I can imagine us going for several more months like this, perhaps
through August.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life
Bruce Momjian wrote:
Hiroshi Inoue wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
Is anyone feeling we have the 7.3 release nearing?
No way!
I certainly am not.
I can imagine us going for several more months like this, perhaps
through August.
Easily. I think that the critical path is Tom's schema support.
We'll need a good beta period this time, because of:
*
Christopher Kings-Lynne wrote:
Is anyone feeling we have the 7.3 release nearing?
No way!
Good.
I certainly am not.
I can imagine us going for several more months like this, perhaps
through August.
Easily. I think that the critical path is Tom's schema support.
We'll need a
Tom,
My feeling is that this change as currently scoped will break a lot of
existing apps. Especially the case where people are using where clauses
of the form: bigintcolumn = '999' to get a query to use the index on
a column of type bigint.
thanks,
--Barry
Tom Lane wrote:
Awhile back
Barry Lind [EMAIL PROTECTED] writes:
My feeling is that this change as currently scoped will break a lot of
existing apps. Especially the case where people are using where clauses
of the form: bigintcolumn = '999' to get a query to use the index on
a column of type bigint.
Eh? That
Neil,
Will this allow you to pass bytea data as binary data in the parameters
section (ability to bind values to parameters) or will this still
require that the data be passed as a text string that the parser needs
to parse. When passing bytea data that is on the order of Megs in size
(thus
OK. My mistake. In looking at the regression failures in your post, I
thought I saw errors being reported of this type. My bad.
--Barry
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
My feeling is that this change as currently scoped will break a lot of
existing apps. Especially
Fernando Nasser wrote:
Hiroshi Inoue wrote:
Fernando Nasser wrote:
As most things in the SQL standard, you have to collect information
from several places and add it together.
Look at 4.20, 11.1 and specially at the rules for
schema qualified name.
Then think a
Fernando Nasser wrote:
As most things in the SQL standard, you have to collect information
from several places and add it together.
Look at 4.20, 11.1 and specially at the rules for
schema qualified name.
Then think a little bit about scenarios, trying to apply the rules.
It is a
Hiroshi Inoue wrote:
Fernando Nasser wrote:
As most things in the SQL standard, you have to collect information
from several places and add it together.
Look at 4.20, 11.1 and specially at the rules for
schema qualified name.
Then think a little bit about scenarios, trying to
Hi everyone,
I know we've already got a rough series of steps to follow when a new
release comes out, but I feel it's worth putting out heads together and
making a cheat sheet of which places to contact, and known good
contacts there.
Am thinking this after coming across the ZDNet download page
Thomas Lockhart [EMAIL PROTECTED] writes:
I do have a concern about how to implement some of the SET commands if
we *do* respect transactional semantics. For example, SET TIME ZONE
saves the current value of an environment variable (if available), and
would need *at least* a before
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
That means that
a lot of low-level places *do* need to know about the dropped-column
convention, else they can't make any sense of tuple layouts.
Why ? As you already mentioned, there were not that many places
to be changed.
There
Hi everyone,
This is Prof. Bayer's response to the question is it alright to use
UB-Tree's in Open Source projects?.
It's a No, but we can discuss a licensing model type answer.
Regards and best wishes,
Justin Clift
Original Message
Subject: AW: More UB-Tree patent
On Wed, 2002-04-10 at 16:32, Justin Clift wrote:
Hi everyone,
This is Prof. Bayer's response to the question is it alright to use
UB-Tree's in Open Source projects?.
Have you found out _what_ exaclty is patented ?
Is it just his concrete implementation of UB-Tree or something
broader, like
Hannu Krosing wrote:
On Wed, 2002-04-10 at 16:32, Justin Clift wrote:
Hi everyone,
This is Prof. Bayer's response to the question is it alright to use
UB-Tree's in Open Source projects?.
Have you found out _what_ exaclty is patented ?
Is it just his concrete implementation of
Justin Clift wrote:
Hi everyone,
I know we've already got a rough series of steps to follow when a new
release comes out, but I feel it's worth putting out heads together and
making a cheat sheet of which places to contact, and known good
contacts there.
Am thinking this after coming
Awhile back I suggested adding a boolean column to pg_proc to control
which type coercion functions could be invoked implicitly, and which
would need an explicit cast:
http://archives.postgresql.org/pgsql-hackers/2001-11/msg00803.php
There is a relevant bug report #484 showing the dangers of too
45 matches
Mail list logo
