Florian G. Pflug wrote:
Tom Lane wrote:
So, to reiterate, my idea is
.) Make "SET TRANSACTION" a synonym for "SET LOCAL" at the SQL-Level.
.) In pl/pgsql, "SET TRANSACTION" sets a new value that is kept after
the
function exits, even if the function has a matching SET-clause.
.) "SET LOCAL
2007/9/4, Tom Lane <[EMAIL PROTECTED]>:
> "Ben Tilly" <[EMAIL PROTECTED]> writes:
> > On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> There seems fairly clear use-case for allowing A-Z a-z 0-9 and
> >> underscore (while CVS head rejects 0-9 and underscore).
>
> > The problem with allowing upper
Tom Lane wrote:
So, to reiterate, my idea is
.) Make "SET TRANSACTION" a synonym for "SET LOCAL" at the SQL-Level.
.) In pl/pgsql, "SET TRANSACTION" sets a new value that is kept after the
function exits, even if the function has a matching SET-clause.
.) "SET LOCAL" in pl/pgsql set a new val
On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ben Tilly" <[EMAIL PROTECTED]> writes:
> > That raises a very random thought. One of the nicer features of
> > Oracle is the ability to have function-based indexes. So you could
> > index, say, trim(lower(person.name)).
>
> > Is there any prospect
In CVS HEAD
workspace=# begin;
BEGIN
workspace=# declare cu cursor for select * from t1 for read only;
DECLARE CURSOR
workspace=# fetch cu;
a
---
1
(1 row)
workspace=# delete from t1 where current of cu;
DELETE 1
workspace=# commit;
COMMIT
Is this the intended behaviour? If so should we remov
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> It still seems a bit strange that "SET LOCAL" is undone at function-exit,
> if the function has a matching SET-clause. But we need that for backwards-
> compatibility of the secure-search_path workaround, right?
Yeah, I'm afraid we backed ourselves
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Clear to everyone? Any objections?
That makes "SET LOCAL" completely equivalent to "SET", except
when used inside a function that has a corresponding SET-clause, right?
Maybe it wasn't clear :-(. They aren't e
"Ben Tilly" <[EMAIL PROTECTED]> writes:
> That raises a very random thought. One of the nicer features of
> Oracle is the ability to have function-based indexes. So you could
> index, say, trim(lower(person.name)).
> Is there any prospect of postgres aquiring that functionality?
Uh, no, since i
On Mon, Sep 03, 2007 at 05:20:34PM -0700, Ben Tilly wrote:
>
> That raises a very random thought. One of the nicer features of
> Oracle is the ability to have function-based indexes. So you could
> index, say, trim(lower(person.name)). There are a *lot* of practical
> situations where that come
On 9/3/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Kenneth Marshall" <[EMAIL PROTECTED]> writes:
>
> > On Sun, Sep 02, 2007 at 10:41:22PM -0400, Tom Lane wrote:
> >> Kenneth Marshall <[EMAIL PROTECTED]> writes:
> >> > ... This is the rough plan. Does anyone see anything critical that
> >> > i
"Ben Tilly" <[EMAIL PROTECTED]> writes:
> On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> There seems fairly clear use-case for allowing A-Z a-z 0-9 and
>> underscore (while CVS head rejects 0-9 and underscore).
> The problem with allowing uppercase letters is that on some
> filesystems foo and
"Ben Tilly" <[EMAIL PROTECTED]> writes:
> I don't know what you're discussing well enough to know if this is
> relevant, but what you just said is not always true. If there is any
> way to pass arbitrary binary data into your function call, then
> someone can pass in a string with nul in it.
Not
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Kenneth Marshall" <[EMAIL PROTECTED]> writes:
>> - What about multi-column indexes? The current implementation
>> only supports 1 column.
> That seems kind of weird. It seems obvious that you mix the three hashes
> together which reduces it to the solve
On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> I'm not convinced that . is issue-free. On most if not all versions of
> >> Unix,
> >> you are allowed to open a directory as a file and read the filenames it
On 9/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On the other hand, this means the name has to be quoted if it would be
> > quoted as an SQL identifier, right?
>
> Something like that. I wasn't planning on rejecting uppercase letters,
> though, which
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Clear to everyone? Any objections?
> That makes "SET LOCAL" completely equivalent to "SET", except
> when used inside a function that has a corresponding SET-clause, right?
Maybe it wasn't clear :-(. They aren't equivalent beca
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
And the rule becomes (I tend to forget things, so I like simple
rules that I can remember ;-) ) "For each SET-clause, there is
a pseudo-subtransaction affecting only *this* GUC".
The other question is whether we want to change the
"Kenneth Marshall" <[EMAIL PROTECTED]> writes:
> On Sun, Sep 02, 2007 at 10:41:22PM -0400, Tom Lane wrote:
>> Kenneth Marshall <[EMAIL PROTECTED]> writes:
>> > ... This is the rough plan. Does anyone see anything critical that
>> > is missing at this point?
>>
>> Sounds pretty good. Let me brai
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> And the rule becomes (I tend to forget things, so I like simple
> rules that I can remember ;-) ) "For each SET-clause, there is
> a pseudo-subtransaction affecting only *this* GUC".
The other question is whether we want to change the behavior of SE
Tom Lane wrote:
> I'm not sure whether we want to touch
> the idea of non-ASCII; comments?
Non-ASCII filenames sounds like recipe for problems to me. We don't know
what encoding the filenames are in on disk.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On the other hand, this means the name has to be quoted if it would be
> quoted as an SQL identifier, right?
Something like that. I wasn't planning on rejecting uppercase letters,
though, which would be necessary if you wanted to be strict about
matchi
Decibel! wrote:
> On Sun, Sep 02, 2007 at 11:18:45PM -0300, Marc G. Fournier wrote:
>> Should be fixed now, running a manual run of it right now, give it about 15
>> minutes or so ...
>
> Is there now monitoring for it as well?
yes
Stefan
---(end of broadcast)
Tom Lane escribió:
> Possibly we could allow '.' as long as we forbade /, but the other
> trouble with allowing . is that it encourages people to try to specify
> the filetype suffix (as indeed Oleg was doing). I'd prefer to keep the
> suffixes out of the SQL object definitions, with an eye to po
Trevor Talbot wrote:
On 9/3/07, Mark Mielke <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
Also, says that Windows throws an error for ":" in the filename,
which means we needn't.
Windows doesn't fail - but it can do odd things. For example, try:
C:\> echo hi >foo:bar
If one then chec
On Mon, Sep 03, 2007 at 10:33:54AM +0100, Simon Riggs wrote:
> >
> > This is the rough plan. Does anyone see anything critical that
> > is missing at this point? Please send me any suggestions for test
> > data and various performance test ideas, since I will be working
> > on that first.
>
> Sou
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
At least for me, the least surprising behaviour would be to
revert it too. Than the rule becomes "a function is always
executed in a pseudo-subtransaction that affects only GUCs"
Only if it has at least one SET clause. The overhea
Moving to -docs
On Sun, Sep 02, 2007 at 06:46:11PM -0400, Tom Lane wrote:
> > Another problem I see are broken examples of dictionary and parser in
> > documentation:
> > http://momjian.us/main/writings/pgsql/sgml/textsearch-rule-dictionary-example.html
> > http://momjian.us/main/writings/pgsql/s
On Sun, Sep 02, 2007 at 10:41:22PM -0400, Tom Lane wrote:
> Kenneth Marshall <[EMAIL PROTECTED]> writes:
> > ... This is the rough plan. Does anyone see anything critical that
> > is missing at this point?
>
> Sounds pretty good. Let me brain-dump one item on you: one thing that
> hash currently
On 9/3/07, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Also, says that Windows throws an error for ":" in the filename,
> > which means we needn't.
> Windows doesn't fail - but it can do odd things. For example, try:
>
> C:\> echo hi >foo:bar
>
> If one then checks the di
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> At least for me, the least surprising behaviour would be to
> revert it too. Than the rule becomes "a function is always
> executed in a pseudo-subtransaction that affects only GUCs"
Only if it has at least one SET clause. The overhead is too high
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
So it seems that only SET LOCAL within a function with per-function
GUC settings is at issue. I think that there is a pretty strong
use-case for saying that if you have a per-function setting of a
particular variabl
pgsql.fc7.noarch.rpm
selinux-policy-2.6.4-38.sepgsql.fc7.src.rpm
* The official documentation
sepgsql_security_guide.20070903.jp.pdf
sepgsql_security_guide.20070903.en.pdf
See the following URL, for installation details.
* SE-PostgreSQL Installation Memo (Fedora 7)
http://code.googl
Simon Riggs <[EMAIL PROTECTED]> writes:
> ISTM that SET LOCAL is mostly superceded by per-function parameters.
Mostly, but not entirely. The case where you still need SET LOCAL is
where the value you want to use locally has to be computed, or where you
need to change it more than once within the
Tom Lane wrote:
Also, says that Windows throws an error for ":" in the filename,
which means we needn't.
Windows doesn't fail - but it can do odd things. For example, try:
C:\> echo hi >foo:bar
If one then checks the directory, one finds a "foo".
Depending on *which* API one uses,
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
On Mon, Sep 03, 2007 at 07:47:14AM +0100, Gregory Stark wrote:
Actually I think in Windows \ : and . are problems (not allowed more
than one dot in dos).
\ and : are problems.
Is : really a problem, given that the name i
"Tom Lane" <[EMAIL PROTECTED]> writes:
> It might still be a good idea to restrict the names to be SQL
> identifiers (ie, alphanumerics and underscores) for future-proofing,
> but it wasn't clear whether anyone but me thought that was a good
> argument. I'm willing to make it just be no-dir-separ
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I'm not convinced that . is issue-free. On most if not all versions of Unix,
>> you are allowed to open a directory as a file and read the filenames it
>> contains. While I don't say it'd be easy to manage that
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I'm not convinced that . is issue-free. On most if not all versions of Unix,
> you are allowed to open a directory as a file and read the filenames it
> contains. While I don't say it'd be easy to manage that through
> tsearch, there's at least a potentia
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Not sure with Windows. I'm strictly a unix type of guy. I'm guessing
> that Windows is detecting too many connections / out of memory and
> shutting down the service.
The whole thing is pretty strange. "received fast shutdown request"
means that the
On Mon, Sep 03, 2007 at 09:27:19AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Mon, Sep 03, 2007 at 07:47:14AM +0100, Gregory Stark wrote:
> >> Actually I think in Windows \ : and . are problems (not allowed more
> >> than one dot in dos).
>
> > \ and : are problems
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Mon, Sep 03, 2007 at 07:47:14AM +0100, Gregory Stark wrote:
>> Actually I think in Windows \ : and . are problems (not allowed more
>> than one dot in dos).
> \ and : are problems.
Is : really a problem, given that the name in question will be appe
Vishnu Aggarwal wrote:
> I am software engineer. i have a problem in postgresql. i am using
> postgresql 8.2.4 version and i have save image in table by java program
> my table fields as id-integer ,image -bytea
>
> i insert image by java in prepared statement by setbinarystream() its
> running p
hello sir
I am software engineer. i have a problem in postgresql. i am using
postgresql 8.2.4 version and i have save image in table by java program
my table fields as id-integer ,image -bytea
i insert image by java in prepared statement by setbinarystream() its
running perfects.
i can retrieve
1. I am not able use fulltext with latin2 encoding :( I missing note
about only utf8 dictionaries in doc).
You can use any server encoding, but dictionary's files should be in utf8 -
dictionary will convert utf8 files into server encoding.
2. with hspell dictionaries (fresh copy from open of
On Mon, 2007-09-03 at 04:09 -0500, Decibel! wrote:
> On Sun, Sep 02, 2007 at 12:08:00PM -0400, Tom Lane wrote:
> > I notice BTW that we have never updated the SET reference page since
> > subtransactions were introduced --- it still says only that SET LOCAL
> > is "local to the current transaction"
On Sun, 2007-09-02 at 13:04 -0500, Kenneth Marshall wrote:
> Dear PostgreSQL Hackers:
>
> After following the hackers mailing list for quite a while,
> I am going to start investigating what will need to be done
> to improve hash index performance. Below are the pieces of
> this project that I am
On Sun, Sep 02, 2007 at 11:18:45PM -0300, Marc G. Fournier wrote:
> Should be fixed now, running a manual run of it right now, give it about 15
> minutes or so ...
Is there now monitoring for it as well?
--
Decibel!, aka Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http:/
On Sun, Sep 02, 2007 at 12:08:00PM -0400, Tom Lane wrote:
> I notice BTW that we have never updated the SET reference page since
> subtransactions were introduced --- it still says only that SET LOCAL
> is "local to the current transaction", without a word about
> subtransactions. So we have a doc
Pavel,
I can't read your posting. Can you use plain text format ?
Oleg
On Mon, 3 Sep 2007, Pavel Stehule wrote:
Hello
I am testing fulltext.
1. I am not able use fulltext with latin2 encoding :( I missing noteabout only
utf8 dictionaries in doc).
2. with hspell dictionaries (fresh copy from
August Zajonc wrote:
> The thing is, the leak occurs in situation where a COMMIT hasn't
> returned to the user, so we are trying to guarantee no data-loss even
> when the user doesn't see a successful commit? That's a tall order
> obviously and hopefully people design their apps to attend to
> tran
On Mon, Sep 03, 2007 at 07:47:14AM +0100, Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> >> "Tom Lane" <[EMAIL PROTECTED]> writes:
> >>> I made it reject all but latin letters, which is the same restriction
> >>> that's in place for
On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Seems a little verbose, but maybe we could do "SET var FROM CURRENT"
> >> or "SET var FROM SESSION"?
>
> > I'd prefer FROM SESSION then. FROM CURRENT s
On Sun, Sep 02, 2007 at 09:57:16PM -0400, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Blah I compiled last night, using the latest snapshot in the
> > postgresql/dev/ directory in ftp, which, as I look now, has a date listed
> > of
> > 2007-08-10, and looking in the source
On 9/2/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Right, traditionally the only characters forbidden in filenames in Unix are /
> and nul. If we want the files to play nice in Gnome etc then we should
> restrict them to ascii since we don't know what encoding the gui expects.
>
> Actually I th
Hello
I am testing fulltext.
1. I am not able use fulltext with latin2 encoding :( I missing note
about only utf8 dictionaries in doc).
2. with hspell dictionaries (fresh copy from open office) I got
different and wrong results.
Original (old) result
ts=# select * from ts_debug('Příliš žluťou
55 matches
Mail list logo
