> 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
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
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
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
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
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
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
"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
"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.
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
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:
>> 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
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
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
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
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
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
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
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
19 matches
Mail list logo
