On Tue, 2008-04-29 at 16:01 -0400, Aidan Van Dyk wrote:
Most of my published applications *are* simple, and I tend to
consolidate as much of my business logic in the database as possible
and a known set of queries shared by all the related apps, relying
heavily on view, triggers, and
I updated the series of SE-PostgreSQL patches for the latest pgsql-8.4devel
tree.
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
[2/4]
I just saw this issue... so though of reporting it before I have to get rid
of the environment.
I `touch`d the trigger file and I saw the following message:
Trigger file: /tmp/pg_standby.trigger.5444
Waiting for WAL file: 0001000B00F2
WAL file path :
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
Peter Eisentraut wrote:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
We do look at COLUMNS if the ioctl() fails, but not for file/pipe
output.
This is
On Mon, Apr 2, 2007 at 2:44 AM, Phil Currier [EMAIL PROTECTED] wrote:
On 4/1/07, Guillaume Smet [EMAIL PROTECTED] wrote:
Phil, did you make any progress with your patch? Your results seemed
very encouraging and your implementation interesting.
IIRC, the problem was that you weren't
On Tue, 29 Apr 2008, Josh Berkus wrote:
Did you guys miss Tom's comment up-thread? Postgres already does this if
you use PQExecParams().
Keen. Now we just need to get the driver developers to implement it. I
imagine Java does.
The JDBC driver takes a multi-command statement and splits
This patch is blocking other work -- for instance, the PrintTable API
and two patches that depend on it.
Could we get the main hunks committed soon, with the policy bits
stripped out? That way, discussion on the behavior can continue until
we reach an agreement, and others can work on other
Peter Eisentraut wrote:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
Peter Eisentraut wrote:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
We do look at COLUMNS if the ioctl() fails, but not for file/pipe
output.
This is quite a useless complication. Readline uses
On Tue, Apr 29, 2008 at 09:02:30PM -0400, Gregory Stark wrote:
Did you guys miss Tom's comment up-thread? Postgres already does this if you
use PQExecParams().
I did, yes. Thanks for the clue. OTOH, I do see the OP's point that
it'd be nice if the DBA could enforce this rule. Maybe a way
Hi,
How many people are using literals in Java?
Not sure if I understood the question... In Java most people use
constants (final static). 'Checkstyle' can find 'magic numbers' in the
source code.
If the constants feature was very important in SQL, people would have
requested it, and it would
Alvaro Herrera [EMAIL PROTECTED] writes:
This patch is blocking other work -- for instance, the PrintTable API
and two patches that depend on it.
Could we get the main hunks committed soon, with the policy bits
stripped out? That way, discussion on the behavior can continue until
we reach
Andrew Dunstan wrote:
Tino Wildenhain wrote:
Hi,
In C the best practice is to use #define for constants. In C++ you
have 'const', in Java 'static final'. Unfortunately the 'named
constant' concept doesn't exist in SQL. I think that's a mistake. I
suggest to support CREATE CONSTANT ... VALUE
Could we also get a mode, where PREPARE would only be allowed for
queries of the form SELECT * FROM func(?,?,?,?,?); :)
Actually, that is similar to the concept of global prepared statements
that I proposed some time ago, but I will not have time to write the
patch, alas...
Idea was
Hi,
Constants are just convenience: instead of constants, user defined
functions can be used. This already works, however it's a bit verbose:
CREATE FUNCTION STATE_ACTIVE() RETURNS VARCHAR AS
$$ BEGIN RETURN 'active'; END; $$ LANGUAGE PLPGSQL;
Usage is almost the same:
SELECT * FROM USERS WHERE
Tom Lane wrote:
This patch seems sufficiently controversial that commit now is the
very last thing that should happen to it.
I suggest committing the PrintTable stuff and not worrying about whether
that breaks the wrap patch.
regards, tom lane\
AFIK, the only thing
Bryce Nesbitt [EMAIL PROTECTED] writes:
AFIK, the only thing that's controversial about the patch is how to turn
it on and off -- the actual core code appears to be inflaming no
passions. And it's the core code that presents merge issues.
Well, personally I haven't read the core code yet,
MERGE looks like it may need some new infrastructure to support it,
depending upon the implementation route. Guidance and discussion
requested from main hackers, if possible.
This is a separate post because there's no further discussion here on
the external behaviour of MERGE, or its
On Wed, Apr 30, 2008 at 8:52 PM, Thomas Mueller
[EMAIL PROTECTED] wrote:
Hi,
Constants are just convenience: instead of constants, user defined
functions can be used. This already works, however it's a bit verbose:
CREATE FUNCTION STATE_ACTIVE() RETURNS VARCHAR AS
$$ BEGIN RETURN
Gurjeet Singh [EMAIL PROTECTED] writes:
Maybe we can extend the SQL's WITH clause do declare the constant along with
the query, and not separate from the query.
WITH CONSTANT c_jobrole = 'clerk', CONSTANT c_dept = 10
SELECT * FROM emp WHERE jobrole = c_jobrole and deptno = c_dept;
[
On Wed, Apr 30, 2008 at 10:58 PM, Tom Lane [EMAIL PROTECTED] wrote:
Gurjeet Singh [EMAIL PROTECTED] writes:
Maybe we can extend the SQL's WITH clause do declare the constant along
with
the query, and not separate from the query.
WITH CONSTANT c_jobrole = 'clerk', CONSTANT c_dept = 10
Hi All,
I noticed that the TidScan fails to identify when the requested block is
not in the relation. Consider this (pg_class has 6 blocks):
postgres=# explain analyze select ctid, * from pg_class where ctid in (
'(6,1)' );
ERROR: could not read block 6 of relation 1663/11511/1259: read
* Gurjeet Singh [EMAIL PROTECTED] [080430 13:38]:
Well, if the the query was:
WITH CONSTANT c_jobrole = value from a FORM text field, CONSTANT c_dept =
10
SELECT * FROM emp WHERE jobrole = c_jobrole and deptno = c_dept;
And if the attack supplied a value 'clerk OR 1=1' the final query
Gregory Stark wrote:
[No I wasn't thinking of that, that's an interesting case too though I think
we might need to think a bit harder about cases that wrap poorly. If you have
long column headings we could wrap those too. But what if you have enough
space for just a few characters per column and
On Wed, Apr 30, 2008 at 10:20:09AM -0400, Andrew Sullivan wrote:
On Tue, Apr 29, 2008 at 09:02:30PM -0400, Gregory Stark wrote:
Did you guys miss Tom's comment up-thread? Postgres already does this if you
use PQExecParams().
I did, yes. Thanks for the clue. OTOH, I do see the OP's point
Gurjeet Singh [EMAIL PROTECTED] writes:
postgres=# explain analyze select ctid, * from pg_class where ctid in (
'(6,1)' );
ERROR: could not read block 6 of relation 1663/11511/1259: read only 0 of
8192 bytes
I was about to say that throwing an error for this is just fine, but on
closer
Martijn van Oosterhout [EMAIL PROTECTED] writes:
void PQexec()
{
die();
}
Actually disabling PQexec seems like a pretty poor decision; it breaks
working code to no purpose. Also, doing it on the client side means
you're at risk of some clients being secure and some not. I thought
what we
Tom Lane wrote:
Well, personally I haven't read the core code yet, since it's not commit fest
yet ;-). I don't know whether there are any issues there, but it wouldn't
surprise me given the number of issues in the control code.
regards, tom lane
I'm biased
On Wed, Apr 30, 2008 at 04:58:52PM +0100, Simon Riggs wrote:
That means we probably need to introduce new infrastructure in the tcop
or executor modules to handle queries-within-queries. This isn't
special-casing MERGE so much as introducing infrastructure for a new
class of query, such as
Folks,
For hackers who don't understand security frameworks, I'm going to make a
strong case for KaiGai's patch. Because of my current presentation
series, I've been talking to PostgreSQL users about security features
around the world for the last several months, and there's a *lot* of
Josh Berkus wrote:
Folks,
So it would be much better to have this functionality be mainstream
rather than a fork. If it does get bounced, please do it becuase of code
quality and not because nobody is asking for this.
+1
Joshua D. Drake
--
Sent via pgsql-hackers mailing list
On 01/05/2008, Josh Berkus [EMAIL PROTECTED] wrote:
Further, I've asked the TrustedSolaris folks to take a look at KaiGai's
implementation to see if it was generic enough for them to build on as a
test of whether SE-Postgres was too specific to SE-Linux; the answer has
been a tentative
On Thu, 1 May 2008, Andrej Ricnik-Bay wrote:
Not a hacker, just a curious reader ... are there equivalent frameworks
for the other supported platforms? E.g. MacOS, *BSD, Windows?
SELinux is a Linux implementation of ideas from an earlier NSA project
named Flask. There is port of another
33 matches
Mail list logo
