Re: [HACKERS] Function proposal to find the type of a datum

On Fri, Feb/ 2/07 02:41:15AM -0500, Tom Lane wrote: > > > Meanwhile, I still think the function David proposed is a worthy > > addition (and I still have a user-case for it!), as using just the OF > > operator for something similar, one would have to explictly test > > against every type required.

[HACKERS] ToDo: add documentation for operator IS OF

Hello, I miss doc for this operator Regards Pavel Stehule _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP

Re: [HACKERS] Function proposal to find the type of a datum

Kate F <[EMAIL PROTECTED]> writes: > ... OF takes a list of types; it needs parentheses: > IF a IS OF (INTEGER) THEN Oh, right, minor detail. > Meanwhile, I still think the function David proposed is a worthy > addition (and I still have a user-case for it!), as using just the OF > operator f

Re: [HACKERS] Function proposal to find the type of a datum

On Fri, Feb/ 2/07 02:17:51AM -0500, Tom Lane wrote: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: > > you can identify type via operator OF. > > > IF a IS OF INTEGER THEN > > RAISE NOTICE 'Parametr a is numeric'; > > Yeah, that is the SQL-standard syntax, but I think our implementation > do

Re: [HACKERS] Function proposal to find the type of a datum

"Pavel Stehule" <[EMAIL PROTECTED]> writes: > you can identify type via operator OF. > IF a IS OF INTEGER THEN > RAISE NOTICE 'Parametr a is numeric'; Yeah, that is the SQL-standard syntax, but I think our implementation doesn't work the way Kate would like: if "a" is an ANYELEMENT function

Re: [HACKERS] writing new regexp functions

On Thu, Feb 01, 2007 at 10:16:54PM -0800, Jeremy Drake wrote: > On Thu, 1 Feb 2007, David Fetter wrote: > > > On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote: > > > Anyway, the particular thing I was writing was a function like > > > substring(str FROM pattern) which instead of return

Re: [HACKERS] Function proposal to find the type of a datum

Hello, you can identify type via operator OF. like: IF a IS OF INTEGER THEN RAISE NOTICE 'Parametr a is numeric'; ELSIF a IS OF varchar THEN RAISE NOTICE 'Parametr a is string'; END IF; Regards Pavel Stehule _ Citite se

Re: [HACKERS] writing new regexp functions

On Thu, 1 Feb 2007, David Fetter wrote: > On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote: > > Anyway, the particular thing I was writing was a function like > > substring(str FROM pattern) which instead of returning just the > > first match group, would return an array of text contai

Re: column ordering, was Re: [HACKERS] [PATCHES] Enums patch v2

Added to TODO: > o Allow column display reordering by recording a display, > storage, and permanent id for every column? > > http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php > --- Jim

Re: [HACKERS] writing new regexp functions

On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote: > On Thu, 1 Feb 2007, Tom Lane wrote: > > > Jeremy Drake <[EMAIL PROTECTED]> writes: > > > Is there some specific reason that these functions are static, > > > > Yeah: not cluttering the global namespace. > > > Is there a reason for no

Re: [HACKERS] Estimation error in n_dead_tuples

Tom Lane <[EMAIL PROTECTED]> wrote: > > I'm thinking to add "the number of vacuumed tuples" to the message from > > vacuum. The stats collector will subtract the value from n_dead_tuples > > instead of setting it to zero. > This seems awfully dangerous to me, because then you are operating on >

Re: [HACKERS] [PATCHES] Full page writes improvement

Tom Lane wrote: > Koichi Suzuki <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Doesn't this break crash recovery on PITR slaves? > >> Compressed archive log contains the same data as full_page_writes off >> case. So the influence to PITR slaves is the same as full_page_writes off. > > Right

Re: [HACKERS] About PostgreSQL certification

Chander Ganesan wrote: Ivo, Iannsp wrote: Hello, I did like to know what you think about the postgresql certifications provided for PostgreSQL CE http://www.sraoss.co.jp/postgresql-ce/news_en.html CertFirst http://www.certfirst.com/postgreSql.htm My question is about the validate of this c

Re: [HACKERS] About PostgreSQL certification

Ivo, Iannsp wrote: Hello, I did like to know what you think about the postgresql certifications provided for PostgreSQL CE http://www.sraoss.co.jp/postgresql-ce/news_en.html CertFirst http://www.certfirst.com/postgreSql.htm My question is about the validate of this certification for the cli

Re: [HACKERS] About PostgreSQL certification

Joshua D. Drake wrote: To cure the shortage of experienced Postgres folks there is only one solution - err, more experience! So the need is for good training courses (not necessarily certification and all the IMHO nonsense that comes with that), and a willingness on the part of employers to inves

[HACKERS] Function proposal to find the type of a datum

Hi all, I found the need to determine the type of a datum at runtime. David Fetter and Elein have already written about this: http://www.varlena.com/varlena/GeneralBits/117.php (My scenario is similar to the article there; I was writing a procedure which unit-tests other procedures. It needs to k

Re: [HACKERS] writing new regexp functions

On Thu, 1 Feb 2007, Tom Lane wrote: > Jeremy Drake <[EMAIL PROTECTED]> writes: > > Is there some specific reason that these functions are static, > > Yeah: not cluttering the global namespace. > Is there a reason for not putting your new code itself into regexp.c? Not really, I just figured it w

Re: [HACKERS] [PATCHES] Full page writes improvement

Koichi Suzuki <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Doesn't this break crash recovery on PITR slaves? > Compressed archive log contains the same data as full_page_writes off > case. So the influence to PITR slaves is the same as full_page_writes off. Right. So what is the use-case f

Re: [HACKERS] [PATCHES] Full page writes improvement

Tom Lane wrote: > Koichi Suzuki <[EMAIL PROTECTED]> writes: >> Here's an idea and a patch for full page writes improvement. > >> Idea: >> (1) keep full page writes for ordinary WAL, make them available during >> the crash recovery, -> recovery from inconsistent pages which can be >> made at the cr

Re: [HACKERS] writing new regexp functions

Jeremy Drake <[EMAIL PROTECTED]> writes: > Is there some specific reason that these functions are static, Yeah: not cluttering the global namespace. I'm not excited about exporting everything that anybody could possibly want access to; that just makes it harder to maintain the code. When you see

Re: [HACKERS] Bitmap index thoughts

On Thu, 1 Feb 2007, Bruce Momjian wrote: > > Where are we on this patch? Does it have performance tests to show > where it is beneificial? Is it ready to be reviewed? I've got an updated patch which adds significant performance improvements for worse case data distributions. It also contains a

Re: [HACKERS] Bitmap index thoughts

Where are we on this patch? Does it have performance tests to show where it is beneificial? Is it ready to be reviewed? --- Heikki Linnakangas wrote: > I've been skimming through the bitmap index patch... > > A scan needs

[HACKERS] writing new regexp functions

I am wanting to write some new C functions which leverage postgresql's existing regexp code in an extension module. I notice that the functions RE_compile_and_cache and RE_compile_and_execute in src/backend/util/regexp.c contain the code necessary to connect the regexp code in src/backend/regex wi

Re: [HACKERS] The may/can/might business

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> 3606c3606 >> > --- >> >errmsg("aggregate function calls may not be nested"))); >> >> I don't think that this is an improvement, or even co

Re: [HACKERS] The may/can/might business

Richard Troy wrote: > > On Thu, 1 Feb 2007, Bruce Momjian wrote: > > From: Bruce Momjian <[EMAIL PROTECTED]> > > Tom Lane wrote: > > > 3606c3606 > > > > > nested"))); > > > --- > > > >errmsg("aggregate function

Re: [HACKERS] The may/can/might business

On Thu, 1 Feb 2007, Bruce Momjian wrote: > From: Bruce Momjian <[EMAIL PROTECTED]> > Tom Lane wrote: > > 3606c3606 > > > --- > > >errmsg("aggregate function calls may not be nested"))); > > > > I don'

Re: [HACKERS] The may/can/might business

Tom Lane wrote: > 3606c3606 > --- > >errmsg("aggregate function calls may not be nested"))); > > I don't think that this is an improvement, or even correct English. > > You have changed a message tha

Re: [HACKERS] [PATCHES] Full page writes improvement

Koichi Suzuki <[EMAIL PROTECTED]> writes: > Here's an idea and a patch for full page writes improvement. > Idea: > (1) keep full page writes for ordinary WAL, make them available during > the crash recovery, -> recovery from inconsistent pages which can be > made at the crash, > (2) Remove them fr

[HACKERS] The may/can/might business

3606c3606 errmsg("aggregate function calls may not be nested"))); I don't think that this is an improvement, or even correct English. You have changed a message that states that an action is logic

Re: [HACKERS] pg_restore fails with a custom backup file

Thread URL added to TODO item: o Add long file support for binary pg_dump output --- Magnus Hagander wrote: > On Fri, Dec 15, 2006 at 12:57:50AM +0900, Hiroshi Saito wrote: > > > > >Win32 does not implement fseeko

Re: [HACKERS] A more general approach (Re: Data archiving/warehousing idea)

Hannu Krosing wrote: > ...is storing all tuple visibility info in a separate file. > > At first it seems to just add overhead, but for lots (most ? ) usecases > the separately stored visibility should be highly compressible, so for > example for bulk-loaded tables you could end up with one bit per

Re: [HACKERS] max_locks_per_transactions ...

Hans-Juergen Schoenig <[EMAIL PROTECTED]> writes: > i would suggest to replace the existing parameter but something else: > - a switch to define the global size of the lock pool (e.g. "max_locks") > - a switch which defines the upper limit for the current backend / > transaction The probl

Re: A more general approach (Re: [HACKERS] Data archiving/warehousing idea)

Hannu Krosing <[EMAIL PROTECTED]> writes: > A more radical variation of the "restricted-use archive table" approach > is storing all tuple visibility info in a separate file. > At first it seems to just add overhead, but for lots (most ? ) usecases > the separately stored visibility should be highl

Re: [HACKERS] Why is ecpg segfaulting on buildfarm member "clownfish"?

Tom Lane wrote: [...] BTW, this is a perfect example of why it's not a good idea to allow minor regression failures to go unfixed --- people become desensitized. I know I've been completely ignoring ECPG-Check buildfarm results for awhile now. I already reported that a while ago: http://archi

[HACKERS] Why is ecpg segfaulting on buildfarm member "clownfish"?

Has anyone looked into $SUBJECT? I just today realized that the ECPG-Check failures on that machine are not the run-of-the-mill small difference in the expected results. Rather, most of the tests are actually dumping core on the client side: testing connect/test1.pgc ... ski

Re: [HACKERS] stack usage in toast_insert_or_update()

Jan Wieck <[EMAIL PROTECTED]> writes: > On 1/31/2007 12:41 PM, Tom Lane wrote: >> We can't change TOAST_MAX_CHUNK_SIZE without forcing an initdb, but I >> think that it would be safe to remove the MAXALIGN'ing of the tuple >> size in the tests in heapam.c, that is > Can't we maxalign the page head

Re: [HACKERS] Estimation error in n_dead_tuples

ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > I'm thinking to add "the number of vacuumed tuples" to the message from > vacuum. The stats collector will subtract the value from n_dead_tuples > instead of setting it to zero. This is also needed if we want to make > some kinds of "partial" vacuum me

Re: [HACKERS] stack usage in toast_insert_or_update()

On 1/31/2007 12:41 PM, Tom Lane wrote: "Pavan Deolasee" <[EMAIL PROTECTED]> writes: On 1/31/07, Tom Lane <[EMAIL PROTECTED]> wrote: The toast code takes pains to ensure that the tuples it creates won't be subject to re-toasting. Else it'd be an infinite recursion. I think I found it. The to

Re: [HACKERS] max_locks_per_transactions ...

Simon Riggs wrote: On Thu, 2007-02-01 at 09:15 +0100, Hans-Juergen Schoenig wrote: Right now max_locks_per_transactions defines the average number of locks taken by a transaction. thus, shared memory is limited to max_locks_per_transaction * (max_connections + max_prepared_transactions). thi

Re: [HACKERS] "May", "can", "might"

Peter Eisentraut wrote: > Bruce Momjian wrote: > > I have made these adjustments to the documentation. Do people want > > the error message strings also updated? > > I have no problem with that. They seem to be in pretty good shape > already, so the changes should be few. Yea, I see only a few

Re: A more general approach (Re: [HACKERS] Dataarchiving/warehousing idea)

On Thu, 2007-02-01 at 14:38 +0200, Hannu Krosing wrote: > Ühel kenal päeval, N, 2007-02-01 kell 13:24, kirjutas Gavin Sherry: > > > A different approach discussed earlier involves greatly restricting the > > way in which the table is used. This table could only be written to if an > > exclusive lo

Re: A more general approach (Re: [HACKERS] Data archiving/warehousing idea)

Ühel kenal päeval, N, 2007-02-01 kell 14:38, kirjutas Hannu Krosing: > Ühel kenal päeval, N, 2007-02-01 kell 13:24, kirjutas Gavin Sherry: > > > A different approach discussed earlier involves greatly restricting the > > way in which the table is used. This table could only be written to if an > >

A more general approach (Re: [HACKERS] Data archiving/warehousing idea)

Ühel kenal päeval, N, 2007-02-01 kell 13:24, kirjutas Gavin Sherry: > A different approach discussed earlier involves greatly restricting the > way in which the table is used. This table could only be written to if an > exclusive lock is held; on error or ABORT, the table is truncated. > > The pr

Re: [HACKERS] Improving NOT IN

On Tue, 2007-01-30 at 17:34 -0500, Tom Lane wrote: > I think the NOT IN optimization that *would* be of use is to > automatically transform the NOT IN representation to an > outer-join-with-null-test type of operation, so as to give us a wider > choice of join methods. However, I'm not sure about

Re: [HACKERS] stack usage in toast_insert_or_update()

On 1/31/07, Tom Lane <[EMAIL PROTECTED]> wrote: We can't change TOAST_MAX_CHUNK_SIZE without forcing an initdb, but I think that it would be safe to remove the MAXALIGN'ing of the tuple size in the tests in heapam.c, that is That would mean that the tuple size in the heap may exceed TOAST_TU

Re: [HACKERS] max_locks_per_transactions ...

On Thu, 2007-02-01 at 09:15 +0100, Hans-Juergen Schoenig wrote: > Right now max_locks_per_transactions defines the average number of locks > taken by a transaction. thus, shared memory is limited to > max_locks_per_transaction * (max_connections + max_prepared_transactions). > this is basically p

Re: [HACKERS] Data archiving/warehousing idea

On Thu, 2007-02-01 at 15:03 +1100, Chris Dunlop wrote: > > A different approach discussed earlier involves greatly > > restricting the way in which the table is used. This table > > could only be written to if an exclusive lock is held; on > > error or ABORT, the table is truncated. > > You're ta

Re: [HACKERS] pg_restore fails with a custom backup file

Still sitting on my TODO. I have a working solution for MSVC, but it didn't run on MingW. Andreas had a working solution on his MingW, but it didn't work on my MingW. I need to merge them together for something that works on all three. I hope to have this done for 8.3, and possibly a 8.2.x, but wil

Re: [HACKERS] "May", "can", "might"

Bruce Momjian schrieb: I have made these adjustments to the documentation. Do people want the error message strings also updated? It will probably make the translation easier/clearer in the future, but it does involve some error message wording churn. CVS HEAD only, of course. I still think

Re: [HACKERS] Data archiving/warehousing idea

On 2/1/07, Chris Dunlop wrote: In maillist.postgres.dev, you wrote: On Thu, 1 Feb 2007, Chris Dunlop wrote: The main idea is that, there might be space utilisation and performance advantages if postgres had "hard" read-only tables, i.e. tables which were guaranteed (by postgres) to never have

Re: [HACKERS] PL/pgSQL RENAME functionality in TODOs

Hello, std. use rename only for triggers and variables new and old. It has sense. I don't see sense for rename in clasic plpgsql functions. There was one reason, rename unnamed $params. But currently plpgsql support named params and this reason is obsolete. Regards Pavel Stehule ___

[HACKERS] Estimation error in n_dead_tuples

AFAICS, the statistics information "the number of dead tuples" (n_dead_tuples) has an estimation error. VACUUM sends a message to stats collector process when it has swept a table. The stats collector receives the message and sets n_dead_tuples of the table to zero. However, we can update or delet

Re: [HACKERS] fixing Makefile.shlib for solaris/gcc with -m64 flag

I dont think we solved this.. But I think the way to put -m64 should be same as in Linux and Solaris and not different. Thanks. Regards, Jignesh Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: Am Mittwoch, 17. Januar 2007 17:12 schrieb Tom Lane: "Jignesh K. Shah" <[EMAIL PROTEC

Re: [HACKERS] PL/pgSQL RENAME functionality in TODOs

On 2/1/07, Tom Lane <[EMAIL PROTECTED]> wrote: imad <[EMAIL PROTECTED]> writes: > OK, so renaming does not work in the same block. > You can rename a vairable in a nested block and thats why it works for OLD/NEW. > BTW, what is the purpose behind it? Declaring a variable in a block > and quickl

Re: [HACKERS] "May", "can", "might"

> I have made these adjustments to the documentation. Do people want the > error message strings also updated? It will probably make the > translation easier/clearer in the future, but it does involve some error > message wording churn. CVS HEAD only, of course. I think most translations will

[HACKERS] max_locks_per_transactions ...

Right now max_locks_per_transactions defines the average number of locks taken by a transaction. thus, shared memory is limited to max_locks_per_transaction * (max_connections + max_prepared_transactions). this is basically perfect. however, recently we have seen a couple of people having troubl