Tom Lane wrote:
It might be nice if manual changes to system objects got dumped,
but that's really an AI-complete problem --- which properties of
the objects represent manual changes, and how can we know whether
trying to apply those changes to a new system version will work?
A diff against te
Tom Lane wrote:
This could be addressed by having the postmaster report its $PGDATA
value in the pg_ping response, but I would be against that on security
grounds. We don't let nonprivileged users know where PGDATA is, why
would we make the information available without any authentication at
al
RE = vc_gt,
LEFTARG = character varying,
RIGHTARG = character varying,
COMMUTATOR = <,
RESTRICT = scalargtsel,
JOIN = scalargtjoinsel
);
CREATE OPERATOR
pruebas=# SELECT ''::varchar < ''::varchar;
ERROR: cache lookup failed for function 0
This was part of my
The following bug has been logged online:
Bug reference: 4120
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Debian Etch + Backports
Description:ERROR: cache lookup failed for function 0
Details:
I have an
Alvaro Herrera wrote:
> Pedro Gimeno escribió:
>
>> Zeos (as well as the Borland Database Engine, which it just mimics in
>> this sense) assumes that VARCHAR fields in general (not just
>> PostgreSQL's) are textual fields with a limit of 255 characters for all
&g
that most operators return TEXT and not
VARCHAR; I just stumbled upon this problem in a query that used MAX().
-- Pedro Gimeno
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 4083
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Irrelevant
Description:Return type of MAX and MIN of a VARCHAR column is TEXT
Details:
Example
x27; <> 'a' || '{true}';
?column?
--
{f,t}
(1 row)
-- Pedro Gimeno
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
aused the need of porting
code, that's not new. Users will very likely appreciate compliance with
the standard even with the hassle of porting the applications, specially
when the fixes, if they're necessary, can easily be made backwards
compatible by using parentheses. For that reason
The following bug has been logged online:
Bug reference: 3822
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Any
Description:Nonstandard precedence for comparison operators
Details:
The operators <>,
ges in a certain sense dropping the "public"
schema (section 5.7.7 of 8.2):
"Also, there is no concept of a public schema in the SQL standard. For
maximum conformance to the standard, you should not use (perhaps even
remove) the public schema."
-- Pedro Gimeno
---
ges in a certain sense dropping the "public"
schema (section 5.7.7 of 8.2):
"Also, there is no concept of a public schema in the SQL standard. For
maximum conformance to the standard, you should not use (perhaps even
remove) the public schema."
-- Pedro Gimeno
---
ogical option for us.
If that's really the case then please add a note in the docs stating
that deleted objects may revive, so it's no surprise for those who face
that for the first time.
-- Pedro Gimeno
---(end of broadcast)
Only the second workaround mentioned is acceptable for us, but it still
feels like a dirty hack. That's why I'd like to see this fixed.
-- Pedro Gimeno
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
fails too?
I'm not in the Debian team but may this help?
http://buildd.debian.org/build.php?arch=alpha&pkg=postgresql-8.2
I'm very interested in 8.2.5 going into Testing for it to reach
Backports, and it turns out that the Alpha build is blocking it.
-
The following bug has been logged online:
Bug reference: 3684
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Debian Etch + Backports
Description:After dump/restore, schema PUBLIC always exists
Details:
In
The following bug has been logged online:
Bug reference: 3637
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: n/a
Operating system: n/a
Description:Path resolving function (feature request)
Details:
There are some applications in which
-- Pedro Gimeno
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Heikki Linnakangas wrote:
Pedro Gimeno wrote:
> When a function has a SQL statement to execute that has an
> unqualified table, that SQL statement doesn't always pick the table
> from a schema in the search_path.
The first time the function is run, all the statements in it are
p
The following bug has been logged online:
Bug reference: 3628
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux (Debian stable + backports)
Description:Wrong schema picked
Details:
When a function has a SQL
The following bug has been logged online:
Bug reference: 3627
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux (Debian stable + backports)
Description:Triple FK with ON DELETE SET NULL makes DELETE fail
I got a broader view of the whole picture and obviously my proposal
that the superuser automatically revokes the privileges granted by all
others does not make sense. So let me state the solutions I propose to
the problem I'm facing:
(1) In the documentation for REVOKE, after the paragraph
On 05/30/2007 08:44:19 PM, Pedro Gimeno Fortea wrote:
Note that this is not similar to the GRANT case. I'd say it's similar
to wanting to delete a table created by another user: if you're not
the owner, you can't, unless you're a superuser. The similarity
becom
On 05/30/2007 07:55:58 PM, Tom Lane wrote:
Pedro Gimeno Fortea <[EMAIL PROTECTED]> writes:
> Still, is silently ignoring the command the proper action to take
> when the REVOKE is executed by the superuser and not by the
> grantor?
You want a warning when REVOKE didn't
On 05/30/2007 06:57:39 PM, Tom Lane wrote:
Pedro Gimeno Fortea <[EMAIL PROTECTED]> writes:
> On 05/29/2007 03:35:00 PM, Tom Lane wrote:
>> This is not a bug. If you want to revoke the privilege, revoke
>> the GRANT OPTION you originally gave.
> Why should I?
Because
On 05/29/2007 03:35:00 PM, Tom Lane wrote:
"Pedro Gimeno" <[EMAIL PROTECTED]> writes:
> When a USAGE grant on a SCHEMA is given by an user (non-superuser
> in my case), the superuser can't revoke it; instead the REVOKE
> statement is silently ignored.
This is not
The following bug has been logged online:
Bug reference: 3319
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux
Description:Superuser can't revoke grants on a schema given by
aother user
Details:
When a
27 matches
Mail list logo
