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 timezone set filenames. That might be overly
strong, but we definitely have to forbid . and
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š
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 think in
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 the
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 seems unclear.
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 timezone set filenames.
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
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
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
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
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 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,
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
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
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
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 appended
to
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.
Is :
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
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 potential for
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 through
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-separators.
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 in
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, the
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
-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.google.com/p/sepgsql/wiki
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 variable
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
to
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 directory, one
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 has over
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
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 overhead is
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.
Sounds good.
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 checks
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
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
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
matching
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
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 SET
LOCAL
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 brain-dump one item on
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
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 because in the
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 would be
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
contains. While
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 solved problem.
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 a
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 Foo are the
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
is missing at this
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 comes in
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 it's
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
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 into a
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
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 of postgres
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 value that
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 uppercase letters is
55 matches
Mail list logo
