2009/10/20 Bruce Momjian :
> Robert Haas 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 don't have a strong feeling about this. If limiting this to 7-bit
>> characters solves so
Bruce Momjian 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 by twiddling it; bu
Bruce Momjian wrote:
> Itagaki Takahiro wrote:
> > When psql opens a file with -f or \i, it checks first 3 bytes of the
> > file. If they are BOM, discard the 3 bytes and change client encoding
> > to UTF8 automatically.
>
> Seems there is community support for accepting BOM:
> http://arc
Itagaki Takahiro wrote:
> UTF8 encoding text files with BOM (Byte Order Mark) are commonly
> used in Windows, though BOM was designed for UTF16 text originally.
> However, psql cannot read such format even if we set client encoding
> to UTF8. Is it worth supporting those format in psql?
>
> When p
On Mon, 2009-10-19 at 14:08 -0700, Ron Mayer wrote:
> Tom Lane wrote:
> > What are the probabilities that the OpenACSes of the world will just
> > set the value to "backward compatible" instead of touching their code?
>
> Would postgres get considerably cleaner if a hypothetical 9.0 release
> skip
Tom Lane wrote:
> Andrew Dunstan 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
UTF8 encoding text files with BOM (Byte Order Mark) are commonly
used in Windows, though BOM was designed for UTF16 text originally.
However, psql cannot read such format even if we set client encoding
to UTF8. Is it worth supporting those format in psql?
When psql opens a file with -f or \i, it c
Robert Haas 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 don't have a strong feeling about this. If limiting this to 7-bit
> characters solves some nasty encoding problems or som
On Mon, 19 Oct 2009, Jeff Davis wrote:
On Mon, 2009-10-19 at 21:22 -0500, Kevin Grittner wrote:
I'd bet accounts receivable applications often hit that.
(Most payments on recent billings; a sprinkling on older ones.)
I'm sure there are others.
You worded the examples in terms of writes (I thi
Tom Lane wrote:
> "Albe Laurenz" 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
> >> necessa
On Mon, 2009-10-19 at 21:22 -0500, Kevin Grittner wrote:
> I'd bet accounts receivable applications often hit that.
> (Most payments on recent billings; a sprinkling on older ones.)
> I'm sure there are others.
You worded the examples in terms of writes (I think), and we're talking
about read cach
Jeff Davis wrote:
> what kind of scenario
> would involve a stable 90% cache hit ratio for a table?
I'd bet accounts receivable applications often hit that.
(Most payments on recent billings; a sprinkling on older ones.)
I'm sure there are others.
-Kevin
--
Sent via pgsql-hackers mailing
On Mon, Oct 19, 2009 at 4:29 PM, Greg Stark wrote:
> On Mon, Oct 19, 2009 at 4:21 PM, Tom Lane wrote:
>> marcin mank writes:
This proposal is just "hints by the back door", ISTM. As Tom says, there is
a justification for having it on tablespaces but not on individual tables.
>>
>>> If
"Marc G. Fournier" writes:
> Just curious, but with that thought in mind, are we doing any code
> cleanups as far as EOL releases? Ie. is there any code in our tree right
> now that is for 'backward compatibility' for 7.3.x versions that could be
> cleaned out?
Well, we were just trying to pu
On Mon, 19 Oct 2009, Tom Lane wrote:
Ron Mayer writes:
Would postgres get considerably cleaner if a hypothetical 9.0 release
skipped backward compatibility and removed anything that's only
maintained for historical reasons?
Yeah, and our user community would get a lot smaller too :-(
Actual
Hi,
Looking at the code, it seems the $SUBJECT (comment) is obsolete. Indeed, we
can set it with 'ALTER DATABASE foo SET track_*'.
One thing that bothers me is the fact that if i turn it off, do a lot of stuff
and then turn it on my counters will be wrong. :( Maybe should we call
pgstat_reset_cou
After the long trial-and-errors, we learned a few approaches which
use common entry points for both of DAC and MAC were rocky-path more
than what we initially imagined.
So, we came back to the original design. It deploys MAC hooks on
the strategic points of core routines. On the other hand, people
* Tom Lane [091019 18:45]:
> Ron Mayer writes:
> > Would postgres get considerably cleaner if a hypothetical 9.0 release
> > skipped backward compatibility and removed anything that's only
> > maintained for historical reasons?
>
> Yeah, and our user community would get a lot smaller too :-(
>
On Mon, 2009-10-19 at 16:39 -0700, Greg Stark wrote:
> But the long-term strategy here I think is to actually have some way
> to measure the real cache hit rate on a per-table basis. Whether it's
> by timing i/o operations, programmatic access to dtrace, or some other
> kind of os interface, if we
On Mon, Oct 19, 2009 at 5:54 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I've been wondering if it might make sense to have a
>> "random_page_cost" and "seq_page_cost" setting for each TABLESPACE,
>> to compensate for the fact that different media might be faster or
>> slower, and a perce
On Mon, Oct 19, 2009 at 2:54 PM, Kevin Grittner
wrote:
> How about calculating an effective percentage based on other
> information. effective_cache_size, along with relation and database
> size, come to mind.
I think previous proposals for this have fallen down when you actually
try to work out
On Mon, Oct 19, 2009 at 4:21 PM, Tom Lane wrote:
> marcin mank writes:
>>> This proposal is just "hints by the back door", ISTM. As Tom says, there is
>>> a justification for having it on tablespaces but not on individual tables.
>
>> If the parameter is defined as "the chance that a page is in c
marcin mank writes:
>> This proposal is just "hints by the back door", ISTM. As Tom says, there is
>> a justification for having it on tablespaces but not on individual tables.
> If the parameter is defined as "the chance that a page is in cache"
> there is very real physical meaning to it.
We h
> This proposal is just "hints by the back door", ISTM. As Tom says, there is
> a justification for having it on tablespaces but not on individual tables.
If the parameter is defined as "the chance that a page is in cache"
there is very real physical meaning to it. And this is per-table, not
per-t
marcin mank wrote:
I've been thinking about this a bit, too. I've been wondering if it
might make sense to have a "random_page_cost" and "seq_page_cost"
setting for each TABLESPACE, to compensate for the fact that different
media might be faster or slower, and a percent-cached setting for each
Ron Mayer writes:
> Would postgres get considerably cleaner if a hypothetical 9.0 release
> skipped backward compatibility and removed anything that's only
> maintained for historical reasons?
Yeah, and our user community would get a lot smaller too :-(
Actually, I think any attempt to do that w
> "Greg" == Greg Stark writes:
>> Why not? As Andrew pointed out, what we're really trying to
>> accomplish here is consider sub-join plans that are parameterized
>> by a value obtained from an outer relation. I think we shouldn't
>> artificially limit what we consider.
Greg> Am I und
marcin mank writes:
> I thought about making it per-table, but realistically I think most
> people don`t use tablespaces now. I would not want to be telling
> people "to be able to hint the planner to (not) index-scan the table,
> You must move it to a separate tablespace".
Per-table is not physi
Greg Stark writes:
> nested loop
> index scan expecting 1 record
> merge join
> index scan on where col1 = outer.foo and col2
> between a and b
> some other scan
> Ie, where the nested loop is a degenerate nested loop which only
> expects a single value and provides a par
> I thought about making it per-table***space***, but realistically I
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> I've been thinking about this a bit, too. I've been wondering if it
> might make sense to have a "random_page_cost" and "seq_page_cost"
> setting for each TABLESPACE, to compensate for the fact that different
> media might be faster or slower, and a percent-cached setting for each
> table over t
Robert Haas wrote:
> I've been wondering if it might make sense to have a
> "random_page_cost" and "seq_page_cost" setting for each TABLESPACE,
> to compensate for the fact that different media might be faster or
> slower, and a percent-cached setting for each table over top of
> that.
[after
On Mon, Oct 19, 2009 at 2:08 PM, marcin mank wrote:
> Currently random_page_cost is a GUC. I propose that this could be set
> per-table.
Or per-tablespace.
Yes, I think there are a class of GUCs which describe the physical
attributes of the storage system which should be per-table or
per-tables
On Mon, Oct 19, 2009 at 5:08 PM, marcin mank wrote:
> Currently random_page_cost is a GUC. I propose that this could be set
> per-table.
>
> I think this is a good idea for widely-wanted planner hints. This way
> You can say "I do NOT want this table to be index-scanned, because I
> know it is no
Currently random_page_cost is a GUC. I propose that this could be set per-table.
I think this is a good idea for widely-wanted planner hints. This way
You can say "I do NOT want this table to be index-scanned, because I
know it is not cached" by setting it`s random_page_cost to a large
value (an o
Tom Lane wrote:
> What are the probabilities that the OpenACSes of the world will just
> set the value to "backward compatible" instead of touching their code?
Would postgres get considerably cleaner if a hypothetical 9.0 release
skipped backward compatibility and removed anything that's only
main
On Oct 19, 2009, at 3:46 PM, Tom Lane wrote:
Sorry if this is obvious to everyone else, but *when* will the error
throw?
Whenever we do semantic analysis of the particular query or
expression.
That's what I figured.
During CREATE FUNCTION or during runtime? I'm secretly hoping
that it'l
On Sun, Oct 18, 2009 at 12:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> You could probably convince me that a merge join is not going to be
>> too useful (how often can you want a merge join on the inner side of a
>> nested loop?
>
> Why not? As Andrew pointed out, what we're really trying to
2009/10/19 Dave Page :
> On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin 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 applicati
On Oct 19, 2009, at 12:23 PM, Tom Lane wrote:
That is, the specification of options is made outside of the language
in question.
I don't think I particularly care for this. It's inventing a global
mechanism to cover a problem that we currently have one instance of
in one PL. That's a mighty
"Eric B. Ridge" writes:
> On Oct 19, 2009, at 2:47 PM, 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.
> Sorry if this is obvious to
"David E. Wheeler" writes:
> On Oct 19, 2009, at 12:05 PM, Tom Lane wrote:
>> Where exactly would you put the modifier, and why is that better than
>> the existing #option convention?
> CREATE OR REPLACE FUNCTION foo()
> RETURNS BOOLEAN
> LANGUAGE plpgsql WITH opt1, opt2
> AS $$...$$;
> That is,
I wrote:
> Where exactly would you put the modifier, and why is that better than
> the existing #option convention?
BTW, it occurs to me that since that's undocumented, not everyone might
know what I'm talking about. There's some code in plpgsql that allows
you to write
#option dump
at th
On Oct 19, 2009, at 12:05 PM, Tom Lane wrote:
What about adopting the modifier syntax you're adding to COPY?
Where exactly would you put the modifier, and why is that better than
the existing #option convention?
CREATE OR REPLACE FUNCTION foo()
RETURNS BOOLEAN
LANGUAGE plpgsql WITH opt1, opt
On Oct 19, 2009, at 2:47 PM, 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.
Sorry if this is obvious to everyone else, but *when* will the e
Andrew Chernow píše v po 19. 10. 2009 v 14:14 -0400:
> > # ./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 debugg
"David E. Wheeler" 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
>> this but
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 by
Andrew Dunstan 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 backwards com
Merlin Moncure 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 a lot of attract
# ./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
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
b
Tom Lane 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 an Oracle-compat
Robert Haas writes:
> On Mon, Oct 19, 2009 at 1:50 PM, 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'm afraid of it, I'm just not sure I have a better idea. It wouldn't
> bother me a bit if w
On Mon, Oct 19, 2009 at 1:50 PM, Tom Lane wrote:
> Pavel Stehule 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 ident
Pavel Stehule 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 good. But - there will
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 re
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane wrote:
> "David E. Wheeler" 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
> substan
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane wrote:
> "David E. Wheeler" 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
> substan
2009/10/19 Kevin Grittner :
> "David E. Wheeler" 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
Andrew Dunstan 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 passwords w
2009/10/19 Robert Haas :
> On Mon, Oct 19, 2009 at 12:48 PM, Dean Rasheed
> 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 b
"David E. Wheeler" 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 care whether tha
On Mon, Oct 19, 2009 at 12:48 PM, Dean Rasheed
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 becomes lossy, how do you pre
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 proposal
"David E. Wheeler" 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 that "solve" the
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 issu
2009/10/19 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> 2009/10/19 Stephen Frost :
>> > * 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 p
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
CREA
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 adve
* 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,
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 suggest
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 th
Tom Lane escribió:
> Peter Eisentraut 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).
Peter Eisentraut 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 is cur
Robert Haas wrote:
> Tom Lane 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 security"[1]. That's not it's purpose; so an
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
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 writes:
> > > > > Is there a good reason for $subject, other than that the code is
> > > > > entangled
>
Simon Riggs wrote:
>
> On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
> > Tom Lane wrote:
> > > Peter Eisentraut 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 low
David Fetter 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:
http://infocenter.sybase.com/help/index.jsp?topic=/com.
Marko Tiikkaja 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, though.
On Mon, Oct 19, 2009 at 10:36 AM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule
>> 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 ent
On Mon, Oct 19, 2009 at 10:54 AM, Stephen Frost 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 behavior)
>
On Mon, Oct 19, 2009 at 11:21 AM, Alvaro Herrera
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 mean that we are fre
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2009/10/19 Stephen Frost :
> > * 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.
>
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-transacti
2009/10/19 Stephen Frost :
> * 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 function, then I ex
On Mon, Oct 19, 2009 at 3:49 PM, Tom Lane wrote:
> Stephen Frost 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 ju
* 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 prob
Stephen Frost 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' wouldn't help, sin
On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin 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 previously,
the
> 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
>
> http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionst
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Dave Page 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
> the variable
David Fetter 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
> see what y
On Mon, Oct 19, 2009 at 3:17 PM, David Fetter 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:
http://blog.benhall.me.uk/2007/10/sql-connection-ap
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2009/10/19 Heikki Linnakangas :
> > 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, connections from connection pool w
Dave Page writes:
> On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule
> 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 utter nonsense. He's setting
up a st
* 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 sh
"Albe Laurenz" 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 features.
>
Tom Lane wrote:
Merlin Moncure 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 x
I would think
1 - 100 of 144 matches
Mail list logo
