Re: [HACKERS] regexp_matches and regexp_split are inconsistent

> > If you count carefully, you will see that regexp_matches() reports a > match of the pattern at the start of the string and at the end of the > string, and also just before 'c' (after the match to the single space). > However, regexp_split() disregards these "degenerate" matches of the > same pa

Re: [HACKERS] Unexpected VACUUM FULL failure

Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> The reason why XLogAsyncCommitFlush() is ugly is that it doesn't >> actually accomplish a darn thing, as we now see from this failure: >> it does not guarantee that hint bits will get set, because of the >> inexac

Re: [HACKERS] Unexpected VACUUM FULL failure

Gregory Stark <[EMAIL PROTECTED]> writes: > Incidentally, every time it comes up we recommend using CLUSTER or ALTER > TABLE. And explaining the syntax for ALTER TABLE is always a bit fiddly. I > wonder if it would make sense to add a "VACUUM REWRITE" which just did the > same as the noop ALTER TAB

Re: [HACKERS] Wrote a connect-by feature

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Bertram Scharpf wrote: >> Wouldn't the release be a good opportunity for providing >> this little tool? > It would be, except that we are past feature freeze thus if it is good > and we can use it, it will have to wait for 8.4. We are *very* far pas

Re: [HACKERS] Unexpected VACUUM FULL failure

Gregory Stark <[EMAIL PROTECTED]> writes: > "Simon Riggs" <[EMAIL PROTECTED]> writes: >> It would be better to release 8.3 with a new, clean, fast implementation >> of VF, than to release it with code that we *think* is right, but has so >> far proved a source of some truly obscure bugs. > Well bu

Re: [HACKERS] Wrote a connect-by feature

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bertram Scharpf wrote: > Hi, > > Am Donnerstag, 09. Aug 2007, 20:44:21 -0400 schrieb Andrew Dunstan: >> Bertram Scharpf wrote: >>> Am Mittwoch, 08. Aug 2007, 14:04:23 +0200 schrieb Bertram Scharpf: Am Mittwoch, 08. Aug 2007, 00:52:41 +0200 schrie

Re: [HACKERS] Wrote a connect-by feature

Hi, Am Donnerstag, 09. Aug 2007, 20:44:21 -0400 schrieb Andrew Dunstan: > Bertram Scharpf wrote: > >Am Mittwoch, 08. Aug 2007, 14:04:23 +0200 schrieb Bertram Scharpf: > >>Am Mittwoch, 08. Aug 2007, 00:52:41 +0200 schrieb Bertram Scharpf: > >> > >>>

[HACKERS] regexp_matches and regexp_split are inconsistent

I noticed the following behavior in CVS HEAD, using a pattern that is capable of matching no characters: regression=# SELECT foo FROM regexp_matches('ab cde', $re$\s*$re$, 'g') AS foo; foo --- {""} {""} {" "} {""} {""} {""} {""} (7 rows) regression=# SELECT foo FROM regexp_split_to

Re: [HACKERS] Unexpected VACUUM FULL failure

"Simon Riggs" <[EMAIL PROTECTED]> writes: > It would be better to release 8.3 with a new, clean, fast implementation > of VF, than to release it with code that we *think* is right, but has so > far proved a source of some truly obscure bugs. Well building a suitable replacement for VACUUM FULL i

Re: [HACKERS] regexp_split_to_array hangs backend

"Pavel Stehule" <[EMAIL PROTECTED]> writes: > I found small bug > regexp_split_to_array('123456','1'); > regexp_split_to_array('123456','6'); > regexp_split_to_array('123456','.'); > these parameters hangs backend. This code's got more problems than that :-( The one that's bothering me right no

Re: [HACKERS] change name of redirect_stderr?

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Before I wrap up the CSVlog stuff, we need to decide whether or not to change the name of the redirect_stderr setting, and if so to what. The reason is that with CSVlogs it will no longer apply just to stderr (we will require it t

Re: [HACKERS] crypting prosrc in pg_proc

On Fri, 10 Aug 2007, Gregory Stark wrote: "Jonah H. Harris" <[EMAIL PROTECTED]> writes: Obfuscation doesn't really work, it just makes big wigs in companies *think* it's not easily reversible. There is no real security. With enough time and experience, anything can be broken. But that said

Re: [HACKERS] Unexpected VACUUM FULL failure

On Fri, 2007-08-10 at 13:47 -0400, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > On Fri, 2007-08-10 at 11:11 -0400, Tom Lane wrote: > >> If we do that, we don't actually need XLogAsyncCommitFlush() at the start. > >> I'm inclined to remove it just because it's ugly. Comments? >

Re: [HACKERS] crypting prosrc in pg_proc

On 8/10/07, Decibel! <[EMAIL PROTECTED]> wrote: > As I said before, I don't care what security you come up with, *it can > be broken*. The point of security measures isn't to make it impossible > to break the security, it's to make it more difficult than it's worth. I agree... but this type of sec

Re: [HACKERS] Compilation of pg 7.4.17 fails on HP-UX

On 8/10/07, Decibel! <[EMAIL PROTECTED]> wrote: > On Fri, Aug 10, 2007 at 08:08:55AM +0300, Adrian Maier wrote: > > So it looks like this is simply a known issue that hasn't been backpatched. > > I'll simply use 8.2 . > > Ok, I'll bite... if you can use 8.2, why were you trying with 7.4 > instead?

Re: [HACKERS] crypting prosrc in pg_proc

On Fri, Aug 10, 2007 at 12:11:01PM -0700, Steve Atkins wrote: > >If someone just went and did "select * from pg_proc" they could > >claim they > >weren't violating their EULA or any protection you had put in > >place. If they > >went through the trouble having to de-obfuscate it then you would

Re: [HACKERS] Unexpected VACUUM FULL failure

On Fri, Aug 10, 2007 at 07:53:06PM +0100, Gregory Stark wrote: > > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > Another argument is that VACUUM FULL is a dinosaur that should probably > > go away entirely someday (a view I believe you share); it should > > therefore not be allowed to drive the de

Re: [HACKERS] crypting prosrc in pg_proc

On 8/10/07, Gregory Stark <[EMAIL PROTECTED]> wrote: > If someone just went and did "select * from pg_proc" they could claim they > weren't violating their EULA or any protection you had put in place. If they > went through the trouble having to de-obfuscate it then you would have a > strong DMCA c

Re: [HACKERS] crypting prosrc in pg_proc

On Aug 10, 2007, at 12:00 PM, Gregory Stark wrote: "Jonah H. Harris" <[EMAIL PROTECTED]> writes: Obfuscation doesn't really work, it just makes big wigs in companies *think* it's not easily reversible. There is no real security. With enough time and experience, anything can be broken. But

Re: [HACKERS] Fixing insecure security definer functions

3. Add optional clauses to CREATE FUNCTION and ALTER FUNCTION to specify the propath value. I suggest, but am not wedded to, PATH 'foo, bar' PATH NONE Since PATH NONE is the default, it's not really needed in CREATE FUNCTION, but it seems useful to allow it for ALTER FUNCTION.

Re: [HACKERS] crypting prosrc in pg_proc

"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > Obfuscation doesn't really work, it just makes big wigs in companies > *think* it's not easily reversible. > > There is no real security. With enough time and experience, anything > can be broken. But that said, I wonder if having something may be

Re: [HACKERS] Unexpected VACUUM FULL failure

"Tom Lane" <[EMAIL PROTECTED]> writes: > Another argument is that VACUUM FULL is a dinosaur that should probably > go away entirely someday (a view I believe you share); it should > therefore not be allowed to drive the design of other parts of the > system. Incidentally, every time it comes up

Re: [HACKERS] Unexpected VACUUM FULL failure

"Tom Lane" <[EMAIL PROTECTED]> writes: > The reason why XLogAsyncCommitFlush() is ugly is that it doesn't > actually accomplish a darn thing, as we now see from this failure: > it does not guarantee that hint bits will get set, because of the > inexact bookkeeping in clog.c. It might marginally

Re: [HACKERS] crypting prosrc in pg_proc

On 8/9/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote: > If I remember correctly Oracle wrap generates something like bytecode and > each Oracle installation is able to understand them. But It is not possible > decode it back to original form. Regardless of what Oracle tells you, it has always been r

Re: [HACKERS] domain casting?

"Pavel Stehule" <[EMAIL PROTECTED]> writes: > Is possible casting domain? No, because find_coercion_pathway() expects that only base types are listed in pg_cast, so it starts by stripping domains. Function lookup tends to do that too, so it's hard even to declare a function as taking a domain. E

Re: [HACKERS] Unexpected VACUUM FULL failure

"Simon Riggs" <[EMAIL PROTECTED]> writes: > On Fri, 2007-08-10 at 11:11 -0400, Tom Lane wrote: >> If we do that, we don't actually need XLogAsyncCommitFlush() at the start. >> I'm inclined to remove it just because it's ugly. Comments? > I'm not clear why XLogAsyncCommitFlush() is ugly. It's one

[HACKERS] domain casting?

Hello I try casting function for domains. I can do it, but it doesn't work. betal=# create domain mydomain text; CREATE DOMAIN betal=# betal=# create or replace function mydomain_todate(mydomain) betal-# returns date as $$ betal$# select to_date($1, 'MMDD'); betal$# $$ language sql; CREATE

Re: [HACKERS] Unexpected VACUUM FULL failure

On Fri, 2007-08-10 at 11:11 -0400, Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > Gregory Stark wrote: > >> I don't think so since it sounds like he's saying to still sync the log and > >> VACUUM FULL has an exclusive lock on the table. So any committed (or > >> aborted) > >>

Re: [HACKERS] Unexpected VACUUM FULL failure

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: >> I don't think so since it sounds like he's saying to still sync the log and >> VACUUM FULL has an exclusive lock on the table. So any committed (or aborted) >> changes it sees in the table must have been committed or aborted b

Re: [HACKERS] Compilation of pg 7.4.17 fails on HP-UX

On Fri, Aug 10, 2007 at 08:08:55AM +0300, Adrian Maier wrote: > So it looks like this is simply a known issue that hasn't been backpatched. > I'll simply use 8.2 . Ok, I'll bite... if you can use 8.2, why were you trying with 7.4 instead? It sounds like you're paying new-car-prices for something t

Re: [HACKERS] pgcheck - data integrity check

On Fri, Aug 10, 2007 at 05:48:08AM +0200, Rober Mach wrote: > . In near future, I would like to extend the functionality also with a > recovery tool which would be able to repair broken pages. Should the > function also repair the corrupted data on a page, the AccessShare lock > on a relation would

Re: [HACKERS] Unexpected VACUUM FULL failure

Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> writes: > >> "Simon Riggs" <[EMAIL PROTECTED]> writes: >> >>> ISTM that if we call HeapTupleSatisfiesVacuum() with an additional >>> boolean parameter, force, we can tell VF to always set the hint bits in >>> every case, not just HEAP_MOVED_IN

Re: [HACKERS] default_text_search_config and expression indexes

Bruce Momjian wrote: > Heikki Linnakangas wrote: >> Removing the default configuration setting altogether removes the 2nd >> problem, but that's not good from a usability point of view. And it >> doesn't solve the general issue, you can still do things like: >> SELECT * FROM foo WHERE to_tsvector('

Re: [HACKERS] default_text_search_config and expression indexes

Oleg Bartunov wrote: > On Wed, 8 Aug 2007, Bruce Momjian wrote: >> Heikki Linnakangas wrote: >>> If I understood correctly, the basic issue is that a tsvector datum >>> created using configuration A is incompatible with a tsquery datum >>> created using configuration B, in the sense that you won't

[HACKERS] regexp_split_to_array hangs backend

Hello, I found small bug regexp_split_to_array('123456','1'); regexp_split_to_array('123456','6'); regexp_split_to_array('123456','.'); these parameters hangs backend. following patch correct it Regards Pavel Stehule ./regexp.c *** ./regexp.c.orig 2007-08-10 14:17:15.0 +0200 --- .

Re: [HACKERS] communication protocol

Hannu Krosing wrote: Ühel kenal päeval, N, 2007-08-09 kell 17:12, kirjutas Omar Bettin: Why not just set up an ssh2 tunnel with both encryption and compression and access your remote db over that ? I know that possibility, but I'm just thinking probably an "ad hoc" protocol for app

Re: [HACKERS] crypting prosrc in pg_proc

Ühel kenal päeval, N, 2007-08-09 kell 16:54, kirjutas Hans-Juergen Schoenig: > > > > Of course, if your goal is to hide the code from someone snooping > > through the pg_proc relation (on disk), then encryption will > > certainly help (provided the key is properly protected). > > > > > > > >

Re: [HACKERS] crypting prosrc in pg_proc

Ühel kenal päeval, N, 2007-08-09 kell 16:42, kirjutas Hans-Juergen Schoenig: > > > well, the complete analysis is easy - the solution is not. > currently we have basically no option to reduce access to the system > tables. this would be hard anyway as we need those tables for > basically all kin

Re: [HACKERS] comunication protocol

Ühel kenal päeval, N, 2007-08-09 kell 17:12, kirjutas Omar Bettin: > > So, you aren't agree with the compression... > > I have sow the network statistics and in some cases, the network traffic > is very big. > Probably a better setup could increase the performance by a few points > percent but