Heikki Linnakangas wrote:
KaiGai Kohei wrote:
Currently, the ACL_SELECT_FOR_UPDATE privilege is defined as an alias
of ACL_UPDATE as follows:
at src/include/nodes/parsenodes.h:
:
/* Currently, SELECT ... FOR UPDATE/FOR SHARE requires UPDATE privileges */
#define
The following list of patches are the latest SE-PostgreSQL (r1819).
http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.4beta1-r1819.patch
http://sepgsql.googlecode.com/files/sepgsql-02-core-8.4beta1-r1819.patch
http://sepgsql.googlecode.com/files/sepgsql-03-writable-8.4beta1-r1819.patch
Kohei-san, what URL do you want me to list in the 8.4 release notes for
the SE-Linux patches?
---
KaiGai Kohei wrote:
The following list of patches are the latest SE-PostgreSQL (r1819).
On Thu, Apr 16, 2009 at 12:08:37PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
I've failed to keep up with the discussion so I'm not sure where this
conversation has got to! Is the consensus for 8.4 to enable SQL2003
style Ulit escaped literals if and only if
KaiGai Kohei kai...@ak.jp.nec.com writes:
Heikki Linnakangas wrote:
What's the point of doing SELECT FOR UPDATE if you're not actually going
to UPDATE the row? Having separate permissions for SELECT FOR UPDATE and
UPDATE seems useless.
I wonder why SELECT FOR UPDATE need ACL_UPDATE, although
Bruce Momjian br...@momjian.us writes:
Kohei-san, what URL do you want me to list in the 8.4 release notes for
the SE-Linux patches?
What? Why would there be anything in the 8.4 release notes about
SEPostgres?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Sam Mason s...@samason.me.uk writes:
Just noticed that the spec only supports four hex digits;
Better read it again.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Fri, Apr 17, 2009 at 10:15:57AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
Just noticed that the spec only supports four hex digits;
Better read it again.
You're right of course. My ability to read patches seems not to be very
good.
--
Sam http://samason.me.uk/
--
Hi.
I'll like to know how to use the oid in a where clause expressing the
value in form of string or number.
many thanks.
--
atte: Alberto J. Castiñeira P.
AJCP
--
atte: Alberto J. Castiñeira P.
AJCP
On 4/16/09, Marko Kreen mark...@gmail.com wrote:
It's up to UTF8 validator whether to consider non-characters as error.
I checked, and it did not work well, as addunicode() did not set
the saw_high_bit variable.when outputting UTF8. Attached patch fixes it.
Currently is would be NOP as
I wrote:
I had earlier speculated semi-facetiously about ripping out the plpgsql
lexer altogether, but the more I think about it the less silly the idea
looks.
This little project crashed and burned upon remembering that plpgsql
invokes raw_parser() to syntax-check each chunk of SQL that it
Hi.
I'll like to know how to use the oid in a where clause expressing the
value in form of string or number.
many thanks.
--
atte: Alberto J. Castiñeira P.
AJCP
This question is not appropriate for pgsql-hackers. You might try
pgsql-general or pgsql-novice.
Anyhow, it's just:
SELECT * FROM pg_class WHERE oid = 1247;
...Robert
2009/4/17 Alberto J. Castiñeira P. ajcastine...@gmail.com:
Hi.
I'll like to know how to use the oid in a where clause
On Fri, Apr 17, 2009 at 12:12:12PM -0400, Tom Lane wrote:
I wrote:
I had earlier speculated semi-facetiously about ripping out the
plpgsql lexer altogether, but the more I think about it the less
silly the idea looks.
This little project crashed and burned upon remembering that plpgsql
David Fetter wrote:
Speaking of standard_conforming_strings, I know it's late, but if we
make it a requirement now, a lot of problems just go away. Yes, it's
inconvenient, but we're making lots of big changes, so one more
shouldn't halt adoption.
16 days too late ...
--
Alvaro Herrera
On Fri, Apr 17, 2009 at 01:01:39PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Speaking of standard_conforming_strings, I know it's late, but if
we make it a requirement now, a lot of problems just go away.
Yes, it's inconvenient, but we're making lots of big changes, so
one more
On Fri, Apr 17, 2009 at 07:07:31PM +0300, Marko Kreen wrote:
Btw, is there any good reason why we don't reject \000, \x00
in text strings?
Why forbid nulls in text strings?
Have a nice day,
--
Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/
Please line up in a tree and
On Fri, Apr 17, 2009 at 07:01:47PM +0200, Martijn van Oosterhout wrote:
On Fri, Apr 17, 2009 at 07:07:31PM +0300, Marko Kreen wrote:
Btw, is there any good reason why we don't reject \000, \x00
in text strings?
Why forbid nulls in text strings?
As far as I know, PG assumes, like most C
Alvaro Herrera wrote:
David Fetter wrote:
Speaking of standard_conforming_strings, I know it's late, but if we
make it a requirement now, a lot of problems just go away. Yes, it's
inconvenient, but we're making lots of big changes, so one more
shouldn't halt adoption.
16 days too
David Fetter da...@fetter.org writes:
Depends. If we've found show-stopping bugs, as it appears we may have
done, in not requiring standards_conforming_strings, we can't just
pull a MySQL and ship anyhow.
It's hardly a show stopping bug, considering it's been there since
On Fri, Apr 17, 2009 at 02:03:45PM -0400, Andrew Dunstan wrote:
Alvaro Herrera wrote:
David Fetter wrote:
Speaking of standard_conforming_strings, I know it's late, but if
we make it a requirement now, a lot of problems just go away.
Yes, it's inconvenient, but we're making lots of big
On Fri, Apr 17, 2009 at 02:07:55PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Depends. If we've found show-stopping bugs, as it appears we may
have done, in not requiring standards_conforming_strings, we can't
just pull a MySQL and ship anyhow.
It's hardly a show
David Fetter da...@fetter.org writes:
It's hardly a show stopping bug, considering it's been there since
standard_conforming_strings was invented.
A known sploit would be a show-stopper.
We're not turning on standard_conforming_strings right now. We are
*certainly* not forcing it on without
Marko Kreen wrote:
+ if (c 0x7F)
+ {
+ if (GetDatabaseEncoding() != PG_UTF8)
+ yyerror(Unicode escape values cannot be used for code point
values above 007F when the server encoding is not UTF8);
+ saw_high_bit = true;
+ }
Andrew Dunstan and...@dunslane.net wrote:
ISTM that one of the uses of this is to say store the character
that corresponds to this Unicode code point in whatever the database
encoding is
I would think you're right. As long as the given character is in the
user's character set, we should
On 4/17/09, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Andrew Dunstan and...@dunslane.net wrote:
ISTM that one of the uses of this is to say store the character
that corresponds to this Unicode code point in whatever the database
encoding is
I would think you're right. As long
David Fetter wrote:
Is this any better?
So what happens if I do \dfaQ? It should throw an error, yes?
This help line:
+ fprintf(output, _( \\df[S+] [PATTERN] list functions. Add a, n,
t, w for aggregate, normal, trigger, window\n));
needs shortening to below 80 chars (or maybe
On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Is this any better?
So what happens if I do \dfaQ? It should throw an error, yes?
This help line:
+ fprintf(output, _( \\df[S+] [PATTERN] list functions. Add a, n,
t, w for aggregate,
Marko Kreen wrote:
On 4/17/09, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Andrew Dunstan and...@dunslane.net wrote:
ISTM that one of the uses of this is to say store the character
that corresponds to this Unicode code point in whatever the database
encoding is
I would think
On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Is this any better?
So what happens if I do \dfaQ? It should throw an error, yes?
Interesting question.
This help line:
+ fprintf(output, _( \\df[S+] [PATTERN] list functions. Add a, n,
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andrew Dunstan and...@dunslane.net wrote:
ISTM that one of the uses of this is to say store the character
that corresponds to this Unicode code point in whatever the database
encoding is
I would think you're right. As long as the given
Sam Mason s...@samason.me.uk writes:
On Fri, Apr 17, 2009 at 07:01:47PM +0200, Martijn van Oosterhout wrote:
On Fri, Apr 17, 2009 at 07:07:31PM +0300, Marko Kreen wrote:
Btw, is there any good reason why we don't reject \000, \x00
in text strings?
Why forbid nulls in text strings?
As far
On 4/18/09, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andrew Dunstan and...@dunslane.net wrote:
ISTM that one of the uses of this is to say store the character
that corresponds to this Unicode code point in whatever the database
encoding is
Tom Lane t...@sss.pgh.pa.us wrote:
The lexer is *not* allowed to invoke any database operations
(such as pg_conversion lookups)
I certainly hope it's not!
so it cannot perform arbitrary encoding conversions.
I was more questioning whether we should be looking at character
encodings at
Btw, There was a EXPLAIN XML summer of code project, wasn't there ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Kohei-san, what URL do you want me to list in the 8.4 release notes for
the SE-Linux patches?
If desirable, I'll prepare a wiki entry to point the list of patches
and introduce the way to set up SE-PostgreSQL on the v8.4 due to the
stable
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
Heikki Linnakangas wrote:
What's the point of doing SELECT FOR UPDATE if you're not actually going
to UPDATE the row? Having separate permissions for SELECT FOR UPDATE and
UPDATE seems useless.
I wonder why SELECT FOR UPDATE need
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Kohei-san, what URL do you want me to list in the 8.4 release notes for
the SE-Linux patches?
What? Why would there be anything in the 8.4 release notes about
SEPostgres?
I suggested it here and no one objected:
KaiGai Kohei wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Kohei-san, what URL do you want me to list in the 8.4 release notes for
the SE-Linux patches?
If desirable, I'll prepare a wiki entry to point the list of patches
and introduce the way to set up SE-PostgreSQL on
39 matches
Mail list logo
