u235sentinel píše v ne 18. 10. 2009 v 17:50 -0600:
Are you sure about this? When I try to build and don't have openssl in
the lib/include path it claims it needs it. As I'm building 64 bit I
can now build postgres in 64 bit with openssl 98k just fine. However
when I run it I'm getting
Andrew Chernow píše v ne 18. 10. 2009 v 21:09 -0400:
I'm curious if this is a lost hope. My boss is recommending we flatten
the Sun box and install redhat linux (which I'm fine with). I'd rather
not as threading in Solaris is better.
Maybe solaris threads were better 10-15 years ago,
KaiGai Kohei wrote:
When we create a new object, we can provide an explicit security context
to be assigned on the new object, instead of the default one.
To get started, do we really need that feature? It would make for a
significantly smaller patch if there was no explicit security labels on
Bruce Momjian wrote:
Great, added to TODO:
Allow server-side enforcement of password policies
Password checks might include password complexity or non-reuse of
passwords. This facility will require the client to send the password to
the server in
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
When we create a new object, we can provide an explicit security context
to be assigned on the new object, instead of the default one.
To get started, do we really need that feature? It would make for a
significantly smaller patch if there was
On Fri, 2009-10-16 at 12:58 +0100, Dave Page wrote:
I think that covers all the suggestions discussed over the last couple
of days, with the exception of the rejection of \n and similar
characters which I'm still not entirely convinced is worth the effort.
Any other opinions on that? Anything
On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut pete...@gmx.net wrote:
On Fri, 2009-10-16 at 12:58 +0100, Dave Page wrote:
I think that covers all the suggestions discussed over the last couple
of days, with the exception of the rejection of \n and similar
characters which I'm still not
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut pete...@gmx.net wrote:
On Fri, 2009-10-16 at 12:58 +0100, Dave Page wrote:
I think that covers all the suggestions discussed over the last couple
of days, with the exception of the rejection of \n and
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do it?
That'll render it pretty useless, as most applications wouldn't then
be able to set/reset it when it makes sense to
Pavel Stehule wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut pete...@gmx.net wrote:
So this would effectively allow any minimally authorized user to write
whatever they want into the log file whenever they want? Doesn't sound
very safe to me.
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do it?
That'll render it pretty useless, as most applications wouldn't then
be
2009/10/19 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Pavel Stehule wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut pete...@gmx.net wrote:
So this would effectively allow any minimally authorized user to write
whatever they want
On Mon, Oct 19, 2009 at 9:23 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 9:23 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I dislike write access to app name guc for user too.
Pavel Stehule wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do it?
That'll render it pretty useless, as
On Mon, Oct 19, 2009 at 9:36 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Then we have to divide this value to two independent values like
application_name and application_state.
How does that make any difference? That just means we have two values,
at least one of which is still userset,
2009/10/19 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I dislike write access to app name guc for user too. It's not safe.
Maybe only super user can do
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 9:36 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Then we have to divide this value to two independent values like
application_name and application_state.
How does that make any difference? That just means we have two
On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
There are some log parser's and analysers. So people use reduced log
often. The reductions rules should be based on application name. Why
not? And when somebody modifies to appliacation name, then these logs
finish
Pavel Stehule wrote:
2009/10/19 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I dislike write access to app name guc for user too. It's
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
There are some log parser's and analysers. So people use reduced log
often. The reductions rules should be based on application name. Why
not? And when somebody modifies to
2009/10/19 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
2009/10/19 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule
pavel.steh...@gmail.com
wrote:
I dislike write access
On Mon, Oct 19, 2009 at 10:22 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
There are some log parser's and analysers. So people use reduced log
often. The reductions
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 10:22 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
There are some log parser's and analysers. So
On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
sure, you have to fix fulnerable application. But with some
unsophisticated using %a and using wrong tools, the people can be
blind and don't register an SQL injection attack.
If they're logging the statements
Updated patch attached, fixing a silly thinko.
On Fri, Oct 16, 2009 at 12:58 PM, Dave Page dp...@pgadmin.org wrote:
I believe the attached patch is ready for review at the next
commitfest. It does the following:
- Adds a userset GUC called application_name.
- Allows application_name to be
On Mon, 2009-10-19 at 08:47 +0100, Dave Page wrote:
On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut pete...@gmx.net wrote:
On Fri, 2009-10-16 at 12:58 +0100, Dave Page wrote:
I think that covers all the suggestions discussed over the last couple
of days, with the exception of the
On Mon, Oct 19, 2009 at 11:21 AM, Peter Eisentraut pete...@gmx.net wrote:
A user can do that anyway if query logging is turned on, but anyway,
what would you suggest - accept a-zA-Z0-9 and a few other choice
characters only, or just reject a handful (and if so, what)?
Well, either you make
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
sure, you have to fix fulnerable application. But with some
unsophisticated using %a and using wrong tools, the people can be
blind and don't register an SQL injection
On Thu, 2009-10-15 at 13:19 -0400, Robert Haas wrote:
But I don't understand why everyone is
so worked up about having an *optional* *flag* to force plaintext
instead of MD5.
It would be pretty bad usability. Users would be faced with the choice:
you can have secure authentication or good
2009/10/19 Pavel Stehule pavel.steh...@gmail.com:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
sure, you have to fix fulnerable application. But with some
unsophisticated using %a and using wrong tools, the people can
On Mon, Oct 19, 2009 at 12:33 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
sure, you have to fix fulnerable application. But with some
unsophisticated using %a and
On Mon, 2009-10-19 at 09:14 +0200, Albe Laurenz wrote:
Bruce Momjian wrote:
Great, added to TODO:
Allow server-side enforcement of password policies
Password checks might include password complexity or non-reuse of
passwords. This facility will require the client
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 12:33 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
sure, you have to fix fulnerable application. But
On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
It is not practical. I'll log errors. Usually SQL injection generates
lot of errors. Loging all statements has not sense. What is difference
bad and good SQL statement.? Maybe multistatements are good candidates
for
On Sat, Oct 17, 2009 at 03:01:27PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Sounds like a good reason to remove add_missing_from in 8.5.
Seems like the general consensus is that it's okay to do that.
I will go make it happen unless somebody squawks pretty soon...
On Mon, Oct 19, 2009 at 01:00:28PM +0100, Dave Page wrote:
On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It is not practical. I'll log errors. Usually SQL injection generates
lot of errors. Loging all statements has not sense. What is difference
bad and
Andrew Dunstan and...@dunslane.net writes:
Pavel Stehule wrote:
Others GUC has not important role in logs. It's similar as possibility
to change client IP address.
That doesn't even remotely answer the question. How is such a thing a vector
for an SQL injection attack, that does not apply to
2009/10/19 Dimitri Fontaine dfonta...@hi-media.com:
Andrew Dunstan and...@dunslane.net writes:
Pavel Stehule wrote:
Others GUC has not important role in logs. It's similar as possibility
to change client IP address.
That doesn't even remotely answer the question. How is such a thing a vector
Peter Eisentraut wrote:
I don't get why you need 'password' authentication for that.
The point where the password should be checked is not when
the user uses it to logon, but when he or she changes it.
So in my opinion that should be:
This facility will require to send new and changed
On Oct 19, 2009, at 03:44 , Robert Haas wrote:
Suppose we define a new join type called inner_or_left_join. This
means that we've proven that every outer row has at least one join
partner, so that we'll get the same results whichever way we implement
it. We can prove this for either inner
-- monthly_report monthly_process.py:524
select wev from foo;
This feature would be very handy, but not if it requires special permission
to use it.
Superuser permission could not be a problem. Simple security definer
function can do it.
Regards
Pavel
-dg
--
David Gould
Zdenek Kotala wrote:
Andrew Chernow píše v ne 18. 10. 2009 v 21:09 -0400:
I'm curious if this is a lost hope. My boss is recommending we flatten
the Sun box and install redhat linux (which I'm fine with). I'd rather
not as threading in Solaris is better.
Maybe solaris threads were better
On Mon, Oct 19, 2009 at 8:54 AM, Alex Brasetvik a...@brasetvik.com wrote:
On Oct 19, 2009, at 03:44 , Robert Haas wrote:
Suppose we define a new join type called inner_or_left_join. This
means that we've proven that every outer row has at least one join
partner, so that we'll get the same
On Mon, Oct 19, 2009 at 7:34 AM, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2009-10-15 at 13:19 -0400, Robert Haas wrote:
But I don't understand why everyone is
so worked up about having an *optional* *flag* to force plaintext
instead of MD5.
It would be pretty bad usability. Users
On Mon, Oct 19, 2009 at 11:39:58AM +0100, Dave Page wrote:
Excuse me one moment whilst I pick myself up from the floor :-)
Heh!
Can you imagine what a maintenance nightmare that would soon become?
Only vaguely, and that's enough.
Please bear in mind that this feature is based on similar
Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
Is the above form:
with x as (delete .. returning *) insert into y select * from x
going to be allowed? I was informed on irc that it wasn't...it would
have to be written as:
insert into y with x as (delete .. returning *) select * from
Albe Laurenz laurenz.a...@wien.gv.at writes:
Bruce Momjian wrote:
Password checks might include password complexity or non-reuse of
passwords. This facility will require the client to send the password to
the server in plain-text, so SSL and 'password' authentication is
necessary to use this
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
Superuser permission could not be a problem. Simple security definer
function can do it.
Then you've defeated the point of making it superuser-only.
I don't think that changing the app name deserves a warning, to be
perfectly honest. Notice
Dave Page dp...@pgadmin.org writes:
On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I thing, so change of original name should generate warning.
Well, if other people think that's necessary, it's certainly possible.
I think Pavel's entire line of argument is
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2009/10/19 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Or are you saying that it should not be possible for the client to
change the value after connecting? That limits the usefulness with
connection pools.
What I know,
On Mon, Oct 19, 2009 at 3:17 PM, David Fetter da...@fetter.org wrote:
Could you point to a reference for this? It could help the rest of us
see what you're aiming for even better :)
Sure. Here's a nice example from SQL Server as well as related doc links:
David Fetter da...@fetter.org writes:
On Mon, Oct 19, 2009 at 11:39:58AM +0100, Dave Page wrote:
Please bear in mind that this feature is based on similar features in
other DBMSs (and in fact, a feature in the JDBC spec)
Could you point to a reference for this? It could help the rest of us
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Dave Page dp...@pgadmin.org writes:
Well, if other people think that's necessary, it's certainly possible.
I think Pavel's entire line of argument is utter nonsense. He's setting
up a straw man that has nothing to do with any actually likely use of
Sure. Here's a nice example from SQL Server as well as related doc links:
http://blog.benhall.me.uk/2007/10/sql-connection-application-name.html
http://msdn.microsoft.com/en-us/library/ms189770.aspx
On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin c...@ghum.de wrote:
Would'nt this also make sense for PostgreSQL? That is, when no environment
is set, and no SET-command is issued, that the application name becomes the
default?
That needs to be set by the application. As discussed
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I do agree with Peter's concerns about limiting the character set of the
name string, and maybe there should be some sort of length limit too.
I was thinking we might just declare it of type 'name'..
'name'
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think there are basically three behaviors that we could offer:
1. Resolve ambiguous names as plpgsql (historical PG behavior)
2. Resolve ambiguous names as query column (Oracle behavior)
3. Throw error if name is ambiguous (useful for finding
On Mon, Oct 19, 2009 at 3:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I do agree with Peter's concerns about limiting the character set of the
name string, and maybe there should be some sort of length limit too.
I
2009/10/19 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
Superuser permission could not be a problem. Simple security definer
function can do it.
Then you've defeated the point of making it superuser-only.
no. Because when I write security definer
Gokulakannan Somasundaram escribió:
Actually this problem is present even in today's transaction id scenario and
the only way we avoid is by using freezing. Can we use a similar approach?
This freezing should mean that we are freezing the sub-transaction in order
to avoid the sub-transaction
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2009/10/19 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
Superuser permission could not be a problem. Simple security definer
function can do it.
Then you've defeated the point of making it
On Mon, Oct 19, 2009 at 11:21 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Gokulakannan Somasundaram escribió:
Actually this problem is present even in today's transaction id scenario and
the only way we avoid is by using freezing. Can we use a similar approach?
This freezing should
On Mon, Oct 19, 2009 at 10:54 AM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think there are basically three behaviors that we could offer:
1. Resolve ambiguous names as plpgsql (historical PG behavior)
2. Resolve ambiguous names as query column (Oracle
On Mon, Oct 19, 2009 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I thing, so change of original name should generate warning.
Well, if other people think that's necessary,
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
I'm looking at this, and if I understood correctly, you're suggesting
we'd add a WithClause to InsertStmt. Would we also allow this?
Yeah, we could eventually do all that. I think supporting it in SELECT
would be plenty to start with,
David Fetter da...@fetter.org wrote:
Could you point to a reference for this? It could help the rest of
us
see what you're aiming for even better :)
Sybase Adaptive Server Enterprise (ASE)
clientapplname varchar(30) column in sysprocesses table:
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Is there a good reason for $subject, other than that the code is
entangled
with other ALTER TABLE code?
I think it could be lower, but
On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Is there a good reason for $subject, other than that the code is
entangled
On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote:
Peter Eisentraut wrote:
Note that this solution will still not satisfy the original checkbox
requirement.
I guess I misunderstood something there, but I had assumed that the
checkbox item read something like: Does the product offer
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I think Pavel's entire line of argument is utter nonsense.
+1. I can't even understand why we're still arguing about this.
Agreed. One premise of the whole concept was don't even think of
using it for
Peter Eisentraut pete...@gmx.net writes:
On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote:
I guess I misunderstood something there, but I had assumed that the
checkbox item read something like: Does the product offer password
policy enforcement? (to quote Dave Page).
The answer to that
Tom Lane escribió:
Peter Eisentraut pete...@gmx.net writes:
On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote:
I guess I misunderstood something there, but I had assumed that the
checkbox item read something like: Does the product offer password
policy enforcement? (to quote Dave
On Oct 19, 2009, at 7:54 AM, Stephen Frost wrote:
4. Resolve ambiguous names as query column, but throw warning
#4 would be my vote, followed by #3. To be perfectly honest, I'd be a
whole lot happier with a pl/pgsql that let me prefix variable names
with
a '$' or similar to get away from
On Oct 19, 2009, at 8:36 AM, Robert Haas wrote:
I think warnings are too easy to miss, but I agree your other
suggestion. I know you can write function_name.variable_name, but
that's often massively long-winded. We either need a short, fixed
prefix, or some kind of sigil. I previously
* David E. Wheeler (da...@kineticode.com) wrote:
On Oct 19, 2009, at 8:36 AM, Robert Haas wrote:
I think warnings are too easy to miss, but I agree your other
suggestion. I know you can write function_name.variable_name, but
that's often massively long-winded. We either need a short, fixed
Alvaro Herrera wrote:
Except that your first statement is false. It is not possible currently
for any tool to prevent someone from doing ALTER USER joe PASSWORD joe.
A server-side plugin can provide a guarantee that there are no bad
passwords (for some value of bad, and with some possible
I wrote:
A server-side plugin can provide a guarantee that there are no bad
passwords (for some value of bad, and with some possible adverse
consequences). We don't have that today.
BTW, it strikes me that ALTER USER RENAME introduces an interesting
hazard for such a plugin. Consider
CREATE
2009/10/19 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2009/10/19 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
Superuser permission could not be a problem. Simple security definer
function can do it.
Then
On Oct 19, 2009, at 9:29 AM, Stephen Frost wrote:
Uh, what dollar quoting? $_$ is what I typically use, so I wouldn't
expect a $ prefix to cause a problem. I think it'd be more of an
issue
because pl/pgsql still uses $1 and whatnot internally (doesn't it?).
Yes, but that's no more an
David E. Wheeler da...@kineticode.com writes:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in plpgsql. I have got
substantially less than zero interest in proposals
On Oct 19, 2009, at 9:49 AM, Tom Lane wrote:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in plpgsql. I have got
substantially less than zero interest in
On Mon, Oct 19, 2009 at 12:48 PM, Dean Rasheed
dean.a.rash...@googlemail.com wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions is a modified bitmap heap scan.
If the bitmap
David E. Wheeler da...@kineticode.com wrote:
I'd be in favor of a GUC that I could turn on to throw an error
when there's an ambiguity.
I would consider hiding one definition with another very bad form, so
I would prefer to have plpgsql throw an error when that happens. I
don't particularly
2009/10/19 Robert Haas robertmh...@gmail.com:
On Mon, Oct 19, 2009 at 12:48 PM, Dean Rasheed
dean.a.rash...@googlemail.com wrote:
This is a WIP patch to replace the after-trigger queues with TID bitmaps
to prevent them from using excessive amounts of memory. Each round of
trigger executions
Andrew Dunstan and...@dunslane.net writes:
Alvaro Herrera wrote:
We do, if you have you server grabbing passwords from LDAP or whatever
external auth service you use. That would be more secure than anything
mentioned in this thread, because the password enforcement could work on
unencrypted
2009/10/19 Kevin Grittner kevin.gritt...@wicourts.gov:
David E. Wheeler da...@kineticode.com wrote:
I'd be in favor of a GUC that I could turn on to throw an error
when there's an ambiguity.
I would consider hiding one definition with another very bad form, so
I would prefer to have plpgsql
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in
Zdenek Kotala wrote:
I can point on this article:
http://tweakers.net/reviews/649/all/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron.html
Zdenek
Ok so I'm checking everything in my environment. The system actually
builds postgres with openssl98k. Comes back and says it's
Pavel Stehule pavel.steh...@gmail.com writes:
ambiguous identifiers is probably the top reason of some plpgsql's
mysterious errors. More times I found wrong code - sometime really
important (some security checks). I never found good code with
ambiguous identifiers - so for me, exception is
On Mon, Oct 19, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
ambiguous identifiers is probably the top reason of some plpgsql's
mysterious errors. More times I found wrong code - sometime really
important (some security checks). I never
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 19, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC. (I still think you're all wrong, but so be it.)
I'm afraid of it, I'm just not sure I have a better idea.
Tom Lane t...@sss.pgh.pa.us wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC.
Well, it seems dangerous to me, but I'm confident we can cover this
within our shop, so I'm reluctant to take a position on it. I guess
the main question is whether we want to allow
Tom Lane wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC. (I still think you're all wrong, but so be it.)
I can't say I'm happy about it. For one thing, the granularity seems all
wrong. I'd rather be able to keep backwards compatibility on a function
# ./pg_ctl
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
0xfd7fff1cf210 does not fit
Killed
symbol (unknown). Can you turn on debugging symbols? Knowing the
symbol may point to a library that was not compiled
Merlin Moncure mmonc...@gmail.com writes:
Maybe invent a new language handler? plpgsql2 or shorten to pgsql?
Now you can mess around all you want (and maybe fix some other
compatibility warts at the same time).
Well, pl/psm is out there, and might even make it into core someday.
I don't find
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC. (I still think you're all wrong, but so be it.)
I can't say I'm happy about it. For one thing, the granularity seems all
wrong. I'd rather be able to keep
On Oct 19, 2009, at 11:47 AM, Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory
default,
at least for a few releases, will be throw-error. Make it SUSET so
that
unprivileged users can't break things
David E. Wheeler da...@kineticode.com writes:
On Oct 19, 2009, at 11:47 AM, Tom Lane wrote:
2. Also invent a #option syntax that allows the GUC to be overridden
per-function. (Since the main GUC is SUSET, we can't just use a
per-function SET to override it. There are other ways we could do
1 - 100 of 142 matches
Mail list logo
