Robert Haas wrote:
I think you have to resign yourself to the fact that a user who can
see only a subset of the rows in a table may very well see apparent
foreign-key violations. But so what?
So you're leaking information about the rows that they're not supposed
to be able to see. This is not
In libpq, the definition is like:
PGresult *
PQprepare(PGconn *conn,
const char *stmtName, const char *query,
int nParams, const Oid *paramTypes)
Could we remove the parameter "nParams"?
e.g. "insert into foo(id, name, address) values ($1, $2, $3)"
PostgreSQL possibly can parse the prepare
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> You mean her data just disappears? Doesn't sound very reasonable to me.
>
>> Well, she actually gets an error rather than a query with missing data,
>> which is proabably the best we are going to do, unless we don'
On Sep 25, 2008, at 20:45, Tom Lane wrote:
Well, there are two possible interpretations: (1) it's a bug, or (2)
it's an intentional, about-to-be-documented feature that
backslashing a
letter makes it case-sensitive in ILIKE.
I do not care for interpretation #2 ... especially in view of your
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
> 2) Do we want row-level permissions at the SQL level?
Now I'm working for it and will submit patches due to the end of Oct,
if it is really required to make progress reviewing of SE-PostgreSQL
on the v8.4 development cycle.
How
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So I'm for the definition that escape-anything means exactly anything,
>> without any special treatment that it would otherwise have. And in
>> the case of ILIKE it seems like "no special treatment" should mean
>> "case insensitive ma
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The docs actually don't state what are the semantics of escape followed
by something that is not escape or a metachar. Does the spec say
anything about that?
The spec says it's an error, per the SQL92 excerpt I quoted in the
>> I think you have to resign yourself to the fact that a user who can
>> see only a subset of the rows in a table may very well see apparent
>> foreign-key violations. But so what?
>
> So you're leaking information about the rows that they're not supposed
> to be able to see. This is not what I
Robert Haas wrote:
You mean her data just disappears? Doesn't sound very reasonable to me.
In reference cases, we can consider she looks the tables via something
like VIEWs implicitly. The "VIEW" can hide several tuple, but it does
not break any reference consistency in the raw level.
I don't
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The docs actually don't state what are the semantics of escape followed
> by something that is not escape or a metachar. Does the spec say
> anything about that?
The spec says it's an error, per the SQL92 excerpt I quoted in the
previous thread. (SQL
>> You mean her data just disappears? Doesn't sound very reasonable to me.
>
> In reference cases, we can consider she looks the tables via something
> like VIEWs implicitly. The "VIEW" can hide several tuple, but it does
> not break any reference consistency in the raw level.
I don't understand
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You mean her data just disappears? Doesn't sound very reasonable to me.
> Well, she actually gets an error rather than a query with missing data,
> which is proabably the best we are going to do, unless we don't
> implement row-level
Tom Lane wrote:
Good:
regression=# select 'T' ilike 't';
?column?
--
t
(1 row)
Not so good:
regression=# select 'T' ilike E'\\t';
?column?
--
f
(1 row)
ISTM backslash is only supposed to turn off the pattern-language
specialness of characters, not render them case se
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> 4. User charlie revokes alice's membership in admin.
>>>
>>> Now what? Alice's FK constraint is violated, according to the rules
>>> KaiGai proposes. Shall REVOKE have to grovel through every table in the
>>> datab
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I think you have to resign yourself to the fact that a user who can
> see only a subset of the rows in a table may very well see apparent
> foreign-key violations. But so what?
So you're leaking information about the rows that they're not supposed
to be
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> 4. User charlie revokes alice's membership in admin.
> >>
> >> Now what? Alice's FK constraint is violated, according to the rules
> >> KaiGai proposes. Shall REVOKE have to grovel through every table in the
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 4. User charlie revokes alice's membership in admin.
>>
>> Now what? Alice's FK constraint is violated, according to the rules
>> KaiGai proposes. Shall REVOKE have to grovel through every table in the
>> database looking for possibl
>> I like the idea of a WITH ROW SECURITY option to enable row-level
>> security - that way, tables that don't need it don't have to pay for
>> it, but I like the idea of storing a full ACL, as KaiGai proposed,
>> rather than just a single role. Seems much more powerful.
> ... and even more ill-de
Tom Lane wrote:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>>> This is just a different syntax for KaiGai's label storage
>>> implementation. It doesn't really answer any of the hard questions,
>>> like what the heck is the behavior of foreign keys.
>
>> What do you find inadequate about KaiGai'
Good:
regression=# select 'T' ilike 't';
?column?
--
t
(1 row)
Not so good:
regression=# select 'T' ilike E'\\t';
?column?
--
f
(1 row)
ISTM backslash is only supposed to turn off the pattern-language
specialness of characters, not render them case sensitive. The reason
t
Tom Lane wrote:
> 4. User charlie revokes alice's membership in admin.
>
> Now what? Alice's FK constraint is violated, according to the rules
> KaiGai proposes. Shall REVOKE have to grovel through every table in the
> database looking for possible violations ... and of course locking the
> enti
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I like the idea of a WITH ROW SECURITY option to enable row-level
> security - that way, tables that don't need it don't have to pay for
> it, but I like the idea of storing a full ACL, as KaiGai proposed,
> rather than just a single role. Seems much mor
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Here is how I think SQL-level row permissions would work:
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SE
"Robert Haas" <[EMAIL PROTECTED]> writes:
>> This is just a different syntax for KaiGai's label storage
>> implementation. It doesn't really answer any of the hard questions,
>> like what the heck is the behavior of foreign keys.
> What do you find inadequate about KaiGai's answers to those hard
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Here is how I think SQL-level row permissions would work:
>
>> We already have an optional OID system column that can be specified
>> during table creation (WITH OIDS). We could have another optional oid
>> column (WITH ROW SECURITY)
> Here is how I think SQL-level row permissions would work:
>
> We already have an optional OID system column that can be specified
> during table creation (WITH OIDS). We could have another optional oid
> column (WITH ROW SECURITY) called security_context which would store the
> oid of the role t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Here is how I think SQL-level row permissions would work:
>
> > We already have an optional OID system column that can be specified
> > during table creation (WITH OIDS). We could have another optional oid
> > column (WITH ROW SECURI
> This is just a different syntax for KaiGai's label storage
> implementation. It doesn't really answer any of the hard questions,
> like what the heck is the behavior of foreign keys.
What do you find inadequate about KaiGai's answers to those hard questions?
...Robert
--
Sent via pgsql-hacke
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Here is how I think SQL-level row permissions would work:
> We already have an optional OID system column that can be specified
> during table creation (WITH OIDS). We could have another optional oid
> column (WITH ROW SECURITY) called security_context
Simon Riggs <[EMAIL PROTECTED]> writes:
> Version 7
After reading this for awhile, I realized that there is a rather
fundamental problem with it: it switches into "consistent recovery"
mode as soon as it's read WAL beyond ControlFile->minRecoveryPoint.
In a crash recovery situation that typically
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> >> > 2) Do we want row-level permissions at the SQL level?
> >>
> >> Now I'm working for it and will submit patches due to the end of Oct,
> >> if it is really required to make progress reviewing of SE-PostgreSQL
> >> on the v8.4 development cyc
Simon Riggs <[EMAIL PROTECTED]> writes:
> Seems like GIST should be able to fake a backwards scan if needed.
Well, it tries --- there is logic in there that pays attention to the
scan direction. Like I say, I don't know the extent of the difficulty.
If we were to decide that it's unfixable, the
On Thu, 2008-09-25 at 12:27 -0400, Tom Lane wrote:
> Mark Cave-Ayland <[EMAIL PROTECTED]> writes:
> > Following up a report on the PostGIS bugtracker (also submitted to
> > pgsql-bugs here:
> > http://archives.postgresql.org/pgsql-bugs/2008-09/msg00086.php), I'm
> > wondering if there is a bug
No problem, I have time for clearing. But are these functions
guaranteed to be included in the contrib? If there is no guarantee,
seems the time of clearing will be wasted. (5 years ago I have already
cleaned one open-source library on demand and after that it was not
approved for PEAR repository,
Tom Lane wrote:
> I think adding a subobject column to pg_shdepend is probably the best
> answer --- we only didn't do that to start with because we thought it
> wasn't needed.
Yep. I did consider adding it, but there was no use for it at the time
so I just left it out. It's not like it's very
Mark Cave-Ayland <[EMAIL PROTECTED]> writes:
> Following up a report on the PostGIS bugtracker (also submitted to
> pgsql-bugs here:
> http://archives.postgresql.org/pgsql-bugs/2008-09/msg00086.php), I'm
> wondering if there is a bug in the way that GiST indexes interact with
> scroll cursors.
On Mon, 2008-09-22 at 18:41 +0100, Gregory Stark wrote:
> The easiest way to fix this seems like also the best way, instead of storing a
> boolean store the pointer to the release function.
Implemented as suggested. v5 enclosed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Trainin
On Thu, 25 Sep 2008, Simon Riggs wrote:
I would suggest we either alter pg_settings so that we display value
*only* when source=default (set NULL otherwise) or we do some extra work
to derive what the setting would be if we ran RESET. The latter would be
preferred approach.
Since getting the v
Hi there,
Following up a report on the PostGIS bugtracker (also submitted to
pgsql-bugs here:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00086.php), I'm
wondering if there is a bug in the way that GiST indexes interact with
scroll cursors.
I've managed to reproduce the bug using b
Gevik Babakhani wrote:
Advantage of C++ is that it reduce lot of OO code written in
C in PostgreSQL, but it is so big effort to do that without
small gain. It will increase number of bugs. Do not forget
also that C++ compiler is not so common (so good) on
different platforms. If somebody inter
On Thu, 2008-09-25 at 09:15 -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > It sounds like you are making the case for what I write above? Having
> > one column named reset_val and one named boot_val should work, no?
>
> Well, that's what I've been saying right along, but
On Thu, 2008-09-25 at 14:52 +0200, Magnus Hagander wrote:
> Simon Riggs wrote:
> > On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
> >> Having
> >> one column named reset_val and one named boot_val should work, no?
> >
> > Yes, those names seem very appropriate to me.
> >
> > Finding t
On 9/25/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > Gevik Babakhani napsal(a):
>
> >> I have not investigated this yet. But I am very interested to know what the
> >> advantages would be to "upgrade" the code to C99 standards.
>
> > I think replace mac
Magnus Hagander <[EMAIL PROTECTED]> writes:
> It sounds like you are making the case for what I write above? Having
> one column named reset_val and one named boot_val should work, no?
Well, that's what I've been saying right along, but the previous
discussion was all about what to call the column
Simon Riggs wrote:
> On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
>> Having
>> one column named reset_val and one named boot_val should work, no?
>
> Yes, those names seem very appropriate to me.
>
> Finding the reset_val isn't that tough, IIRC the way the guc assignment
> works with
On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
> If both are interesting to different audiences, perhaps we should be
> exposing both as separate columns?
That seems best. It will make things much clearer.
> Having
> one column named reset_val and one named boot_val should work, no?
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> We have an RESET command which "returns parameter to its default
>> setting". But what this means is "return it to the value set in current
>> the postgresql.conf, if overriden therein from its default value". So it
>> would be useful to
Simon Riggs <[EMAIL PROTECTED]> writes:
> We have an RESET command which "returns parameter to its default
> setting". But what this means is "return it to the value set in current
> the postgresql.conf, if overriden therein from its default value". So it
> would be useful to have a column that mea
On Thu, 2008-09-25 at 12:34 +0200, Zeugswetter Andreas OSB sIT wrote:
> > > I wonder whether the cancel can be delayed until a tuple/page is actually
> > > accessed
> > > that shows a too new xid.
> >
> > Yes, its feasible and is now part of the design.
> >
> > This is all about what happens *if*
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Gevik Babakhani napsal(a):
>> I have not investigated this yet. But I am very interested to know what the
>> advantages would be to "upgrade" the code to C99 standards.
> I think replace macros with inline functions. It brings to ability to
> monitor th
> Are you saying the performance penalty when full functionalities are
> enabled?
> (The meaning of "bells and whistles" is unclear for me.)
Yes, that's what I meant. (Sorry.)
> We can show it on the page.22 of my presentation in PGcon2008.
> http://www.pgcon.org/2008/schedule/attachments/38_p
> > I wonder whether the cancel can be delayed until a tuple/page is actually
> > accessed
> > that shows a too new xid.
>
> Yes, its feasible and is now part of the design.
>
> This is all about what happens *if* we need to remove rows that a query
> can still see.
I was describing a procedure
Gevik Babakhani napsal(a):
Better idea is to start to use C99 in PostgreSQL ;-).
I have not investigated this yet. But I am very interested to know what the
advantages would be to "upgrade" the code to C99 standards.
I think replace macros with inline functions. It brings to ability to
moni
On Wed, 2008-09-24 at 21:22 -0400, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > 2. Master ignores Standby's OldestXmin
> > > Effects:
> > > * Long running queries on standby...
> > >Have no effect on primary
> > >Can delay apply of WAL records on standby
> > > *
On Thu, 2008-09-25 at 11:14 +0200, Zeugswetter Andreas OSB sIT wrote:
> > Simon Riggs wrote:
> > > 2. Master ignores Standby's OldestXmin
> > > Effects:
> > > * Long running queries on standby...
> > >Have no effect on primary
> > >Can delay apply of WAL records on standby
> > > * Queries
> Advantage of C++ is that it reduce lot of OO code written in
> C in PostgreSQL, but it is so big effort to do that without
> small gain. It will increase number of bugs. Do not forget
> also that C++ compiler is not so common (so good) on
> different platforms. If somebody interesting in that
> Simon Riggs wrote:
> > 2. Master ignores Standby's OldestXmin
> > Effects:
> > * Long running queries on standby...
> >Have no effect on primary
> >Can delay apply of WAL records on standby
> > * Queries on standby give consistent answers in all cases.
>
> Just for clarification, if you
Gevik Babakhani napsal(a):
Dear PG hackers,
Has there been any idea to port PG to a more modern programming language
like C++? Of course there are some minor obstacles like a new OO design,
this being a gigantic task to perform and rewriting almost everything etc...
I am very interested to hear
On Tue, 2008-09-16 at 00:10 -0400, Greg Smith wrote:
> Attached is an updated and separate version of my patch exposing the
> internal GUC boot_val as default_val, which failed to attach itself to the
> already committed changes to the pg_settings view.
>
> Brief reminder of what it does:
>
>
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
I'm testing this version now and I got core dump in initdb phase:
08047558 pgstat_count_heap_insert+0x20(840b120, 842d738, 80, 8047580)
Let me know if you need more info. (I'm not using fresh CVS snapshot
but two weeks old)
pgstat_coun
Hi,
Markus Wanner wrote:
As mentioned in above, regression tests, documentation updates,
dependency handling, and actually implementing the permission checks all
remain. What I'm looking for feedback on are the changes to the
grammer, parser, catalog changes, psql output, etc.
Aha, good. So I
On Wed, 2008-09-24 at 21:19 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > 2. Master ignores Standby's OldestXmin
> > Effects:
> > * Long running queries on standby...
> >Have no effect on primary
> >Can delay apply of WAL records on standby
> > * Queries on standby give consistent a
Heikki Linnakangas napsal(a):
Attached is a revamped version of the FSM rewrite. WAL-logging is now
gone. Any inconsistencies between levels of the FSM is fixed during
vacuum, and by searchers when they run into a dead end because of a
discrepancy. Corruption within FSM pages is likewise fixed
63 matches
Mail list logo