The following bug has been logged online:
Bug reference: 1312
Logged by: Amie
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: windows 2000 prof
Description:the ordinal 2821 could not be located
Details:
At the point when the inst
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As much as I would like the URERLIMIT hacks removed for 8.0 I am thinking
> > we are too far along in release and don't have enough time to figure out
> > how to do the security definer function cleanly.
>
> What does that have to do
zohn_ming wu <[EMAIL PROTECTED]> writes:
> What exactly does that mean??? What is going on?
Looks like a corrupted index to me. Have you tried REINDEXing the
pkey index?
regards, tom lane
---(end of broadcast)---
TIP 8: ex
Hello All
Both server and psql are 7.4.5 and both running linux.
I have a table with a primary key as follow
Column | Type |
Modifiers
++-
email | c
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As much as I would like the URERLIMIT hacks removed for 8.0 I am thinking
> we are too far along in release and don't have enough time to figure out
> how to do the security definer function cleanly.
What does that have to do with it? We aren't the ones
Andrew McMillan wrote:
-- Start of PGP signed section.
> On Tue, 2004-11-09 at 13:58 -0500, Tom Lane wrote:
> >
> > Bruce and I were chatting about this on the phone today, and we were
> > seriously considering a more radical proposal: get rid of the whole
> > concept of USERLIMIT variables, and m
If, by some quirk of fate, you manage to delete the logical link to a
tablespace in pg_tblspc, then you try to access a table in that
tablespace, you get an error message that says:
ERROR: could not open relation 15254222/17230/15254223: No such file or
directory
This is somewhat misleading. Th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why not? You can put whatever restrictions you like in such a function.
> I assume to do this in a function you would have to create a temp table
> to store the original setting?
Not at all. You could use "RESET foo" to see what the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Sure. There is a workaround for that though, which is to provide a
> >> SECURITY DEFINER function for the app to call that will adjust the
> >> logging level for it, rather than trying to do the SET directly in
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Sure. There is a workaround for that though, which is to provide a
>> SECURITY DEFINER function for the app to call that will adjust the
>> logging level for it, rather than trying to do the SET directly in
>> unprivileged code.
> But
"Riccardo G. Facchini" <[EMAIL PROTECTED]> writes:
> creating a table that inherits from another two tables with "WITHOUT
> OIDS" generates a table "WITH OIDS",
This is not a bug. If either parent table has oids then the child must
as well. It's just like inheriting a regular column.
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> Quick and dirty [and not really portable] patch:
s/not really/not at all/
AFAICS this would take some fairly significant surgery in configure to
even have a prayer of working --- there's no reason to assume that the
host compiler has the same f
Tom Lane wrote:
> Andrew McMillan <[EMAIL PROTECTED]> writes:
> > The current functionality could be useful inside particular code paths
> > of an application, where you want to increase the log verbosity in a
> > particular part of the code, when it (unpredictably) happens, without
> > nuking the
Andrew McMillan <[EMAIL PROTECTED]> writes:
> The current functionality could be useful inside particular code paths
> of an application, where you want to increase the log verbosity in a
> particular part of the code, when it (unpredictably) happens, without
> nuking the logs entirely.
> Of course
If PostgreSQL failed to compile on your computer or you found a bug
that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem
The following bug has been logged online:
Bug reference: 1311
Logged by: Bernhard Rosenkraenzer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: Ark Linux
Description:Can't crosscompile
Details:
Hi,
8.0.0beta4 can't be crosscompil
On Tue, 2004-11-09 at 13:58 -0500, Tom Lane wrote:
>
> Bruce and I were chatting about this on the phone today, and we were
> seriously considering a more radical proposal: get rid of the whole
> concept of USERLIMIT variables, and make the logging variables be plain
> SUSET (ie, only superusers c
Dear debuggers,
I'd like to report the following "strange" behavior that I encountered
while trying (a bad idea, I know) to use a rule as a "poor man sql-trigger".
It seems that "on update do also" rules the new.* fields are evaluated
several times instead of being computed once, which is a bad id
> The following bug has been logged online:
>
> Bug reference: 1310
> Logged by: Tom O'Connell
>
> Email address: [EMAIL PROTECTED]
>
> PostgreSQL version: 8.0 Beta
>
> Operating system: Windows 2000 Professional
>
> Description:libecpg.dll missing from msi package
19 matches
Mail list logo
