Sunday, July 13, 2008

Re: [PERFORM] Trigger is not firing immediately

Praveen wrote:
>
> Hi All,
> I am having a trigger in table, If I update the the table manually
> trigger is firing immediately(say 200ms per row), But if I update the
> table through procedure the trigger is taking time to fire(say 7 to 10
> seconds per row).
>
> Please tell me what kind of changes can I make so that trigger fire
> immediately while updating the table through procedure ?

Sending the same email over and over again isn't going to get you a
response any quicker.

If you send the details of the trigger and the tables/fields it affects
then you might get a more helpful response.

--
Postgresql & php tutorials
http://www.designmagick.com/

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Trigger is not firing immediately

am Mon, dem 14.07.2008, um 12:04:49 +0530 mailte Praveen folgendes:
>
> Hi All,
> I am having a trigger in table, If I update the the table manually trigger
> is firing immediately(say 200ms per row), But if I update the table through
> procedure the trigger is taking time to fire(say 7 to 10 seconds per row).
>
> Please tell me what kind of changes can I make so that trigger fire
> immediately while updating the table through procedure ?

Show us more details like source-code of the procedure, the trigger and
a demonstration.


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA

http://wwwkeys.de.pgp.net

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [HACKERS] PATCH: CITEXT 2.0 v3

On Jul 13, 2008, at 10:31, Tom Lane wrote:

>> Grr. Kind of defeats the purpose. Is there no infrastructure for
>> testing multibyte functionality?
>
> There's some stuff under src/test/locale and src/test/mb, though it
> doesn't get exercised regularly. The contrib tests are a particularly
> bad place for trying to do any locale-dependent testing, because we
> only support "make installcheck" which means there is no way to set
> the database locale --- you *have to* work with whatever locale is
> predetermined by the postmaster you're pointed at.
>
> I don't recall the reason for not supporting "make check" in the
> contrib
> modules; maybe it was just that preparing a test installation for each
> contrib module sounded too slow? In any case, what you'd need to
> pursue
> is having some additional tests available that are not executed by the
> standard contrib regression test sequence.
>
> (If we get to having per-database collations in 8.4 then integrating a
> test with a non-default collation would get a lot easier, of course;
> but for the moment I'm afraid you've got to work with what's there.)

Could I supply two comparison files, one for Mac OS X with en_US.UTF-8
and one for everything else, as described in the last three paragraphs
here?

http://www.postgresql.org/docs/current/static/regress-variant.html

That way, I can at least make sure that the multibyte stuff *does*
work. Even if it's tested on only one platform, the purpose is not to
test a particular collation, but to test that CITEXT is actually
sensitive to locale.

Thanks,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0 v3

On Jul 13, 2008, at 10:19, Tom Lane wrote:

>>> You might try running the
>>> opr_sanity regression test on this module to see if it finds any
>>> other silliness. (Procedure: insert the citext definition script
>>> into the serial_schedule list just ahead of opr_sanity, run tests,
>>> make sure you understand the reason for any diffs in the opr_sanity
>>> result. There will be at least one from the uses of text-related
>>> functions for citext.)
>
>> Thanks. Added to my list.
>
> BTW, actually a better idea would be to put citext.sql at the front of
> the list and just run the whole main regression series with it
> present.
> typ_sanity and oidjoins might possibly find issues too.

Um, stupid question (sorry, I'm not familiar with how the regression
tests are organized): serial_schedule doesn't look like a file into
which I can insert an SQL file. How would I do that?

Thanks,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[PERFORM] Trigger is not firing immediately

 
Hi All,
    I am having a trigger in table, If I update the the table manually trigger is firing immediately(say 200ms per row), But if I update the table through procedure the trigger is taking time to fire(say 7 to 10 seconds per row).
 
Please tell me what kind of changes can I make so that  trigger  fire immediately while updating the table through procedure ?
 
Regards,
Praveen

Re: [SQL] how to perform minus (-) operation in a dynamic query

am Mon, dem 14.07.2008, um 11:21:17 +0530 mailte Anoop G folgendes:
> SELECT mf,sf,(mf mf * comm /100) (sf sf * comm/100) as flt_claim;
^^^ ^^^ ^^^

That's not valid SQL.


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA

http://wwwkeys.de.pgp.net

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

[PERFORM] Trigger is taking time to fire

 

Hi All,
    I am having a trigger in table, If i update the the table manually it is not taking time(say 200ms per row), But if i update the table through procedure the trigger is taking time to fire(say 7 to 10 seconds per row).
 
How can i make the trigger to fire immediately ?
 
Regards,
Ram

[SQL] how to perform minus (-) operation in a dynamic query


Hai all,

I am new to plpgsql ,I have a  table  structure:

 Column |       Type       | Modifiers
--------+------------------+-----------
 mf     | double precision |
 sf     | double precision |
 comm   | integer          |

I create a  the following funtion

create or replace function test_perc() returns setof record as $body$

declare

vchr_query VARCHAR(100);

r record;

begin

vchr_query:= 'SELECT mf,sf,(mf – mf * comm /100) – (sf – sf * comm/100) as flt_claim';

FOR r in EXECUTE vchr_query LOOP

RETURN NEXT r;

END LOOP;

RETURN;

end$body$
language 'plpgsql'


function created

but when I am traing to run this function I got the following error

ERROR:  syntax error at or near "–" at character 18
QUERY:  SELECT mf,sf,(mf – mf * comm /100) – (sf – sf * comm/100) as flt_claim
CONTEXT:  PL/pgSQL function "test_perc" line 7 at for over execute statement
LINE 1: SELECT mf,sf,(mf – mf * comm /100) – (sf – sf * comm/100) as...


How I can solve this ,pls help me


thanks in advance:
Anoop



[pgadmin-support] Hi..need support for WKT polygon..


Hi...

I need help for using PostGIS Geomtry Datatype(WKT)  for a polygon...

How to use polygon(11,222,33,44) in PostGIS...
















S.Prabhakar,
9908117812


Share files, take polls, and make new friends - all under one roof. Click here.

[pgadmin-support] Hi...need support for WKT polygon

Hi...

I am prabhakar from RSI Softech...

i need support for wkt polygon....

i am able to use wkt(str) for a point ..but i am unable to use Geomtry Dattype(WKT) for a polygon...

so i need ur support for that...

thanks & Regards...

prabhkar

Re: [GENERAL] Top N within groups?

Martijn van Oosterhout wrote:
> On Fri, Jul 11, 2008 at 01:24:28PM +1000, Klint Gore wrote:
> > [thinking out loud]
> > Can someone familiar with the source for DISTINCT ON comment on how hard
> > it would be to add another parameter to return more than one row?
>
> From a programming point of view, it wouldn't be too hard. However,
> deciding what syntax to use is a another question entirely. I think
> your suggestion of FOR isn't good (ambiguous syntax, 'for' could be a
> column name), but I can't think of a better one.
>
'for' is a reserved key word so can't be a column name.

http://www.postgresql.org/docs/8.3/interactive/sql-keywords-appendix.html

postgres=# create table foo (for int);
ERROR: syntax error at or near "for"

The worst I think you could get would be
select distinct on ("for") for 4 "for" from table4 for update;

but even then, I think the parser could work out what you want.

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789
Fax: 02 6773 3266
EMail: kgore4@une.edu.au


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[ADMIN] Rewrite SELECT WHERE clause on per-session bases. Modifing view source code in one session (user's) from another session (admin's)?

Hi!
In my application's security scheme I'm planing to restrict users to view only particular "types" of records,
where "types" is set of WHERE predicates for each view, dynamically defined in application.
I believe it's most efficient way to do such things, instead of calling some decision function for each row
in view's SELECT, for example.

So, for these porposes I need some mechanism allowing "on the fly" modification of view's SELECT's.
At the beggining I review CREATE RULE ON SELECT variant, but rules are "database-wide" not "session-wide" and
SELECT rules don't allow WHERE clause.

My current solution is creating temporary viwes for each application user with
appropriate WHERE restrictions at the session begining (but rules could be more convient).
By this way view permissions (what "types" user can select fron view) are can't be changed during session
(user can't modify view by design).

So question is: is it possible to modify view source code in one session (user's) from another session (admin's)?
Or may be more convenient way to rewrite SELECT WHERE clause on per-session bases exist (similar to RULES)?
Thanks.


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [HACKERS] gsoc, text search selectivity and dllist enhancments

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> Isn't the vacuum_delay_point() good enough?

> But that's in the outer loop ... I mean here:

You'd need one heckuva lot of lexemes in a tsvector to make that
important. Do we have CHECK_FOR_INTERRUPTS() in any other loops
over tsvector contents? I kinda doubt it ...

(I have no real objection to adding CHECK_FOR_INTERRUPTS there,
I'm just questioning the value.)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] gsoc, text search selectivity and dllist enhancments

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Should we have a CHECK_FOR_INTERRUPTS() call in the inner loop of
> > compute_tsvector_stats?
>
> Isn't the vacuum_delay_point() good enough?

But that's in the outer loop ... I mean here:

Index: src/backend/tsearch/ts_typanalyze.c
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/tsearch/ts_typanalyze.c,v
retrieving revision 1.1
diff -c -p -r1.1 ts_typanalyze.c
*** src/backend/tsearch/ts_typanalyze.c 14 Jul 2008 00:51:45 -0000 1.1
--- src/backend/tsearch/ts_typanalyze.c 14 Jul 2008 04:59:59 -0000
*************** compute_tsvector_stats(VacAttrStats *sta
*** 206,211 ****
--- 206,213 ----
{
bool found;

+ CHECK_FOR_INTERRUPTS();
+
/* Construct a hash key */
hash_key.lexeme = lexemesptr + curentryptr->pos;
hash_key.length = curentryptr->len;

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] Restoring Database from Data directory backup.

J Ottery wrote:
> Using XP Pro and Postgres 8.3
> I made a backup of the "Data" directory of the Postgres Installation
> to another place on the hard disk.
> Now the customer has uninstalled postgres then reinstalled a new one.
> Of course the original tables are all gone.
> Is there a method of retrieving the original tables and data from the
> backedup Data directory.
>
>
If you can get the same version that they used to have you, should be
able to start it on the same platform. Look for the PG_VERSION file in
the data directory.

Download from http://www.postgresql.org/ftp/binary/

I'm assuming that your backup took the entire directory tree under data
and postgres wasn't running when you did it?

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789
Fax: 02 6773 3266
EMail: kgore4@une.edu.au


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[BUGS] BUG #4303: insufficient privileges

The following bug has been logged online:

Bug reference: 4303
Logged by: Alexandre
Email address: abrunelle@gmail.com
PostgreSQL version: 8.2
Operating system: Windows xp
Description: insufficient privileges
Details:

Hi,

I have been getting the following error everytime I tried to install
PostgreSQL:

Service 'PostgreSQL Database Server 8.2' (pgsql-8.2) failed to start. Verify
that you have sufficient privileges to start system services

I am loged in as an administrator.
I searched forums etc... but found no clear answers...

Im really desperate ! Can't solve this stupid problem...

Can you help me ?

Thank you

Alexandre

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [GENERAL] Requirements For Postgresql Database

aravind chandu wrote:
> Hello,
>
> I just need the information related to the requirements of postgresql
> database like how much size it occupies on the disk (when it is
> installed) irrespective of tables size and how much RAM is needed for
> better performance of the database say, I have 4gb ram will it use
> all the 4gb ram or 2gb is sufficient in terms of usage and
> performance issues.
>
> Thank You, Aravind.
>

My install takes up about 33MB - depending on what options and any
add-ons like slony or postgis that you may add can increase that.

Your data can use many TB of disk space if you have the data and the
space for it.

RAM usage will depend on your system - 32 bit versions will max out a
little short of 4GB (I think it is about 2.5GB), you will need a 64 bit
system and postgresql binaries to use more RAM than that.
Whether postgresql can make use of that much RAM will depend on how you
configure postgresql, how many concurrent connections will be running
and whether your data is large enough to take advantage of it.

If you have some estimates on the size of your db (number of tables,
columns in each, expected number of rows, concurrent users, types of
queries) then you may get some guesses about whether 2 or 4 GB will
suit your situation.

--

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] gsoc, text search selectivity and dllist enhancments

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Should we have a CHECK_FOR_INTERRUPTS() call in the inner loop of
> compute_tsvector_stats?

Isn't the vacuum_delay_point() good enough?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [sydpug] Hello

On Mon, Jul 14, 2008 at 12:43 PM, Bastiaan Olij <lists@basenlily.nl> wrote:
> Just wanted to say hello after joining up. Just moved from the Netherlands
> to Sydney Australia to work for a company that uses Postgresql as one of
> their backends. My own experience has been mostly Sybase and lately MS SQL
> Server so I'm relatively new to Postgresql all though I've been playing
> around with it for the past few months.
>

Welcome. There ought to be a meeting fairly soon (probably early
August). Please be sure and come along!

Thanks,

Charles Duffy

--
Sent via sydpug mailing list (sydpug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/sydpug

Re: [HACKERS] gsoc, text search selectivity and dllist enhancments

Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j.urbanski@students.mimuw.edu.pl> writes:
> > OK, here's the (hopefully final) version of the typanalyze function for
> > tsvectors. It applies to HEAD and passes regression tests.
>
> > I now plan to move towards a selectivity function that'll use the
> > gathered statistics.
>
> Applied with some revisions.

Should we have a CHECK_FOR_INTERRUPTS() call in the inner loop of
compute_tsvector_stats?

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCHES] VACUUM Improvements - WIP Patch

(taking the discussions to -hackers)

On Sat, Jul 12, 2008 at 11:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>
> (2) It achieves speedup of VACUUM by pushing work onto subsequent
> regular accesses of the page, which is exactly the wrong thing.
> Worse, once you count the disk writes those accesses will induce it's
> not even clear that there's any genuine savings.
>

Well in the worst case that is true. But in most other cases, the
second pass work will be combined with other normal activities and the
overhead will be shared, at least there is a chance for that. I think
there is a chance for delaying the work until there is any real need
for that e.g. INSERT or UPDATE on the page which would require a free
line pointer.


> (3) The fact that it doesn't work until concurrent transactions have
> gone away makes it of extremely dubious value in real-world scenarios,
> as already noted by Simon.
>

If there are indeed long running concurrent transactions, we won't get
any benefit of this optimization. But then there are several more
common cases of very short concurrent transactions. In those cases and
for very large tables, reducing the vacuum time is a significant win.
The FSM will be written early and significant work of the VACUUM can
be finished quickly.

> It strikes me that what you are trying to do here is compensate for
> a bad decision in the HOT patch, which was to have VACUUM's first
> pass prune/defrag a page even when we know we are going to have to
> come back to that page later. What about trying to fix things so
> that if the page contains line pointers that need to be removed,
> the first pass doesn't dirty it at all, but leaves all the work
> to be done at the second visit? I think that since heap_page_prune
> has been refactored into a "scan" followed by an "apply", it'd be
> possible to decide before the "apply" step whether this is the case
> or not.
>

I am not against this idea. Just that it still requires us double scan
of the main table and that's exactly what we are trying to avoid with
this patch.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pdxpug] [pgsql-advocacy] Pg booth staffing at OSCON

On Sun, Jul 13, 2008 at 7:31 PM, gabrielle <gorthx@gmail.com> wrote:
>
> PS: Michael - what kind of balloons should I provide for you? :)

I'll be bringing my own, thanks. ;)

Looking forward to seeing y'all at OSCON! :)

---Michael Brewer
mbrewer@gmail.com

--
Sent via pdxpug mailing list (pdxpug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pdxpug

Re: [GENERAL] Restoring Database from Data directory backup.

On Jul 14, 12:57 pm, J Ottery <jott...@becsystems.com.au> wrote:
> Using XP Pro and Postgres 8.3
> I made a backup of the "Data" directory of the Postgres Installation
> to another place on the hard disk.
> Now the customer has uninstalled postgres then reinstalled a new one.
> Of course the original tables are all gone.
> Is there a method of retrieving the original tables and data from the
> backedup Data directory.
> I hope so or I am in shit.

AS a follow up. The problem is I can no longer start the Postgres
Server (just says starting).

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[COMMITTERS] pgsql: Clean up buildfarm failures arising from the seemingly

Log Message:
-----------
Clean up buildfarm failures arising from the seemingly straightforward page
macros patch :-(. Results from both baiji and mastodon imply that MSVC
fails to perceive offsetof(PageHeaderData, pd_linp[0]) as a constant
expression in some contexts where offsetof(PageHeaderData, pd_linp) works
fine. Sloth, thy name is Micro.

Modified Files:
--------------
pgsql/src/include/storage:
bufpage.h (r1.82 -> r1.83)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/bufpage.h?r1=1.82&r2=1.83)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [torontopug] Next meeting planning

On Sun, 13 Jul 2008, Ian Bailey wrote:

> There was some interest on replication at the last meeting, so
> presenting on the options might be a good idea.

Then a presentation on the different replication options it will be.
Everyone invite your friends.

--
Sent via torontopug mailing list (torontopug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/torontopug

[GENERAL] Restoring Database from Data directory backup.

Using XP Pro and Postgres 8.3
I made a backup of the "Data" directory of the Postgres Installation
to another place on the hard disk.
Now the customer has uninstalled postgres then reinstalled a new one.
Of course the original tables are all gone.
Is there a method of retrieving the original tables and data from the
backedup Data directory.
I hope so or I am in shit.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Default fill factor for tables?

On Sat, Jul 12, 2008 at 2:25 AM, Roberts, Jon <Jon.Roberts@asurion.com> wrote:
>>
>> --
>
> I can find very little information on hot updates but I found this: http://archives.postgresql.org/pgsql-patches/2006-11/msg00059.php
>
> It states, "This design optimizies the updates when none of the index columns are modified and length of the tuple remains the same after update."
>
> How can a row's length change? I think it must mean the size (in bytes) of the row remains the same.
>

I bet you are looking at an old design. That has undergone many
changes and the current implementation does not have any restriction
about the row length changes. But a necessary condition is to have
enough free space in the block (and of course not changing any index
columns).

You can find the latest README in the source code under
src/backend/access/heap/README.HOT

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[sydpug] Hello

Hey Everyone,

Just wanted to say hello after joining up. Just moved from the
Netherlands to Sydney Australia to work for a company that uses
Postgresql as one of their backends. My own experience has been mostly
Sybase and lately MS SQL Server so I'm relatively new to Postgresql all
though I've been playing around with it for the past few months.

Kindest Regards,

Bastiaan Olij
http://www.linkedin.com/in/bastiaanolij


--
Sent via sydpug mailing list (sydpug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/sydpug

Re: [GENERAL] REQUIREMENTS FOR POSTGRESQL DATABASE


In the future could you please refrain from using caps in your subject line.  It looks like you are screaming. 
 
thx

[ANNOUNCE] == PostgreSQL Weekly News - July 13 2008 ==

== PostgreSQL Weekly News - July 13 2008 ==

== PostgreSQL Product News ==

Open Technology Group has created a high-availability training course.
http://www.otg-nc.com/training-courses/coursedetail.php?courseid=65&cat_id=8

== PostgreSQL Jobs for July ==

http://archives.postgresql.org/pgsql-jobs/2008-07/threads.php

== PostgreSQL Local ==

The Call for Papers for European PGDay has begun.
http://www.pgday.org/en/call4papers

pgDay Portland is July 20, just before OSCON.
http://pugs.postgresql.org/node/400

PGCon Brazil 2008 will be on September 26-27 at Unicamp in Campinas.
http://pgcon.postgresql.org.br/index.en.html

PGDay.(IT|EU) 2008 will be October 17 and 18 in Prato.
http://www.pgday.org/it/

== PostgreSQL in the News ==

Planet PostgreSQL: http://www.planetpostgresql.org/

General Bits, Archives and occasional new articles:
http://www.varlena.com/GeneralBits/

PostgreSQL Weekly News is brought to you this week by David Fetter

Submit news and announcements by Sunday at 3:00pm Pacific time.
Please send English language ones to david@fetter.org, German language
to pwn@pgug.de, Italian language to pwn@itpug.org.

== Applied Patches ==

Peter Eisentraut committed:

- In pgsql/doc/src/sgml/func.sgml, added documentation for function
xmlagg.

- Allow binary-coercible types for cast function arguments and return
types. Document return type of cast functions. Also change
documentation to prefer the term "binary coercible" in its present
sense instead of the previous term "binary compatible".

Tom Lane committed:

- Fix AT TIME ZONE (in all three variants) so that we first try to
interpret the timezone argument as a timezone abbreviation, and only
try it as a full timezone name if that fails. The zic database has
four zones (CET, EET, MET, WET) that are full daylight-savings zones
and yet have names that are the same as their abbreviations for
standard time, resulting in ambiguity. In the timestamp input
functions we resolve the ambiguity by preferring the abbreviation,
and AT TIME ZONE should work the same way. (No functionality is
lost because the zic database also has other names for these zones,
eg Europe/Zurich.) Per gripe from Jaromir Talir. Backpatch to 8.1.
Older releases did not have the issue because AT TIME ZONE only
accepted abbreviations not zone names. (Thus, this patch also
arguably fixes a compatibility botch introduced at 8.1: in ambiguous
cases we now behave the same as 8.0 did.)

- In pgsql/src/backend/utils/adt/selfuncs.c, fix estimate_num_groups()
to assume that GROUP BY expressions yielding boolean results always
contribute two groups, regardless of the expression contents. This
is very substantially more accurate than the regular heuristic for
certain boolean tests like "col IS NULL". Per gripe from Sam Mason.
Back-patch to all supported releases, since the behavior of
estimate_num_groups() hasn't changed all that much since 7.4.

- In pgsql/src/backend/utils/error/elog.c, fix performance bug in
write_syslog(): the code to preferentially break the log message at
newlines cost O(N^2) for very long messages with few or no newlines.
For messages in the megabyte range this became the dominant cost.
Per gripe from Achilleas Mantzios. Patch all the way back, since
this is a safe change with no portability risks. I am also thinking
of increasing PG_SYSLOG_LIMIT, but that should be done separately.

- In pgsql/src/backend/utils/error: elog.c, increase PG_SYSLOG_LIMIT
(the max line length sent to syslog()) from 128 to 1024 to improve
performance when sending large elog messages. Also add a comment
about why we use that number. Since this represents an externally
visible behavior change, and might possibly result in portability
issues, it seems best not to back-patch it.

- Fix mis-calculation of extParam/allParam sets for plan nodes, as
seen in bug #4290. The fundamental bug is that masking extParam by
outer_params, as finalize_plan had been doing, caused us to lose the
information that an initPlan depended on the output of a sibling
initPlan. On reflection the best thing to do seemed to be not to
try to adjust outer_params for this case but get rid of it entirely.
The only thing it was really doing for us was to filter out param
IDs associated with SubPlan nodes, and that can be done (with
greater accuracy) while processing individual SubPlan nodes in
finalize_primnode. This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan
failed to remove extParam bits for initPlan output params that were
referenced in the main plan tree (it only got rid of those
referenced by other initPlans). It's not clear that this caused any
real problems, given the limited use of extParam by the executor,
but it's certainly not what was intended. I originally thought that
there was also a problem with needing to include indirect
dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the
depended-on initPlan is earlier in the initPlans list than the one
using its output. That seems a bit of a fragile assumption, but it
is true at the moment, so I just documented it in some code comments
rather than making what would be rather invasive changes to remove
the assumption. Back-patch to 8.1. Previous versions don't have
the case of initPlans referring to other initPlans' outputs, so
while the existing logic is still questionable for them, there are
not any known bugs to be fixed. So I'll refrain from changing them
for now.

- Tighten up SS_finalize_plan's computation of valid_params to exclude
Params of the current query level that aren't in fact output
parameters of the current initPlans. (This means, for example,
output parameters of regular subplans.) To make this work correctly
for output parameters coming from sibling initplans requires
rejiggering the API of SS_finalize_plan just a bit: we need the
siblings to be visible to it, rather than hidden as
SS_make_initplan_from_plan had been doing. This is really part of
my response to bug #4290, but I concluded this part probably
shouldn't be back-patched, since all that it's doing is to make a
debugging cross-check tighter.

- Add unchangeable GUC "variables" segment_size, wal_block_size, and
wal_segment_size to make those configuration parameters available to
clients, in the same way that block_size was previously exposed.
Bernd Helmle, with comments from Abhijit Menon-Sen and some further
tweaking by me.

- In pgsql/src/backend/utils/time/snapmgr.c, fix a few typos in
comments and sort header inclusions alphabetically.

- Fix an oversight in the original implementation of
performMultipleDeletions(): the alreadyDeleted list has to be passed
down through deleteDependentObjects(), else objects that are deleted
via auto/internal dependencies don't get reported back up to
performMultipleDeletions(). Depending on the visitation order, this
could cause the code to try to delete an already-deleted object,
leading to strange errors in DROP OWNED (typically "cache lookup
failed for relation NNNNN" or similar). Per bug #4289. Patch for
back branches only. This code has recently been rewritten in HEAD,
and doesn't have this particular bug anymore.

- Multi-column GIN indexes. Teodor Sigaev

- Const-ify the arguments of str_tolower() and friends to suppress
compile warnings. Clean up various unneeded cruft that was left
behind after creating those routines. Introduce some convenience
functions str_tolower_z etc to eliminate tedious and error-prone
double arguments in formatting.c. (Currently there seems no need to
export the latter, but maybe reconsider this later.)

- In pgsql/src/include/pg_config_manual.h, don't make --enable-cassert
turn on RANDOMIZE_ALLOCATED_MEMORY automatically; it's just too dang
expensive. Per recent discussion, but I just got my nose rubbed in
it again while doing some performance checking.

- More replacements of binary compatible to binary coercible.

- In pgsql/doc/src/sgml/ref/create_cast.sgml, fix a couple of stray
misuses of "binary compatible".

- Clean up the use of some page-header-access macros: principally, use
SizeOfPageHeaderData instead of sizeof(PageHeaderData) in places
where that makes the code clearer, and avoid casting between Page
and PageHeader where possible. Zdenek Kotala, with some additional
cleanup by Heikki Linnakangas. I did not apply the parts of the
proposed patch that would have resulted in slightly changing the
on-disk format of hash indexes; it seems to me that's not a win as
long as there's any chance of having in-place upgrade for 8.4.

- Change the PageGetContents() macro to guarantee its result is
maxalign'd, thereby forestalling any problems with alignment of the
data structure placed there. Since SizeOfPageHeaderData is
maxalign'd anyway in 8.3 and HEAD, this does not actually change
anything right now, but it is foreseeable that the header size will
change again someday. I had to fix a couple of places that were
assuming that the content offset is just SizeOfPageHeaderData rather
than MAXALIGN(SizeOfPageHeaderData). Per discussion of Zdenek's
page-macros patch.

- Create a type-specific typanalyze routine for tsvector, which
collects stats on the most common individual lexemes in place of the
mostly-useless default behavior of counting duplicate tsvectors.
Future work: create selectivity estimation functions that actually
do something with these stats. (Some other things we ought to look
at doing: using the Lossy Counting algorithm in
compute_minimal_stats, and using the element-counting idea for stats
on regular arrays.) Jan Urbanski

Bruce Momjian committed:

- In pgsql/src/backend/utils/misc/guc.c, add comment for deadlock_timeout:
"This is PGC_SIGHUP so all backends have the same value."

Neil Conway committed:

- In pgsql/src/backend/access/gin/README, minor improvements to the
Gin internal documentation.

Heikki Linnakangas committed:

- In pgsql/contrib/pg_standby/pg_standby.c, fix WAL file cutoff point
calculation in pg_standby. Patch by Simon Riggs, per bug report
from Ferenc Felhoffer.

Alvaro Herrera committed:

- Make sure we only try to free snapshots that have been passed
through CopySnapshot, per Neil Conway. Also add a comment about the
assumption in GetSnapshotData that the argument is statically
allocated. Also, fix some more typos in comments in snapmgr.c.

Teodor Sigaev committed:

- Add caching of query to GIN/GiST consistent function. Per
performance gripe from nomao.com

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Heikki Linnakangas sent in a revision of the page macros cleanup.

Simon Riggs sent in a patch to change PG_USERSET to PG_SUSET for
logging files.

Bernd Helmle sent in a patch which adds some missing descriptions for
aggregates, functions and conversions.

Pavel Stehule, with feedback from Marko Kreen, sent in two more
revisions of his table function support patch.

Ken Camann sent in a patch to get Postgres to compile under 64-bit
Windows.

Jaime Casanova sent in another revision of his patch which makes
granting INSERT on a table extend to any sequences attached.

Tom Lane sent in a revised version of David Wheeler's case-insensitive
text patch.


---------------------------(end of broadcast)---------------------------
-To unsubscribe from this list, send an email to:

pgsql-announce-unsubscribe@postgresql.org

[GENERAL] REQUIREMENTS FOR POSTGRESQL DATABASE

Hello,

                 I just need the information related to the requirements of postgresql database like how much size it occupies on the disk (when it is installed) irrespective of tables size and how much RAM is needed for better performance of the database say, I have 4gb ram will it use all the 4gb ram or 2gb is sufficient in terms of usage and performance issues.

Thank You,
Aravind.

[SOLVED] Re: [PERFORM] Altering a column type - Most efficient way

On Fri, 2008-07-11 at 09:55 -0500, Kevin Grittner wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
> >>> Ow Mun Heng wrote:
> >>> If it were this simple a change, I'm not certain why (I believe) PG
> >>>is checking each and every row to see if it will fit into the new column
> >>> definition/type.
> >Because the code that does the ALTER TYPE is very generic, and it
> > doesn't (yet) have an optimization that tells it to skip the check
> > and the possible table rewrite in the cases where it's obviously not
> >needed(like this one).

> If there's some low-hanging fruit here, +1 for getting that.

I just tested this out and everything seems to be working fine. (cross
fingers - for now and if I do report back, it means we've crashed and
burned, but as of now... the low hanging fruit is tasty)

This 2 sec change is much preferred over the 3+ hour per table.

I agree with Tom that this is not useful in _all_ cases and may seem to
look like a hack, but it really isn't. Given that the condition that
we're expaning the min length rather than the opposite, it should be
pretty safe.


Guys(/gals) Thanks very much for brightening up a dreadry Monday
morning.


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [HACKERS] PATCH: CITEXT 2.0 v3

"David E. Wheeler" <david@kineticode.com> writes:
> To judge by the User-Defined Types docs, I was close. :-) I just
> changed the argument to citextrecv to "internal".

Right. The APIs for send and recv aren't inverses. (Oh, the sins
we'll commit in the name of performance ...)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] gsoc, text search selectivity and dllist enhancments

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j.urbanski@students.mimuw.edu.pl> writes:
> OK, here's the (hopefully final) version of the typanalyze function for
> tsvectors. It applies to HEAD and passes regression tests.

> I now plan to move towards a selectivity function that'll use the
> gathered statistics.

Applied with some revisions.

Rather than making pg_statistic stakind 4 be specific to tsvector,
I thought it'd be better to define it as "most common elements", with
the idea that it could be used for array and array-like types as well as
tsvector. (I'm not actually planning to go off and make that happen
right now, but it seems like a pretty obvious extension.)

I thought it was a bit schizophrenic to repurpose
pg_stats.most_common_freqs for element frequencies while creating a
separate column for the elements themselves. What I've done for the
moment is to define both most_common_vals and most_common_freqs as
referring to the elements in the case of tsvector (or anything else that
has stakind 4 in place of stakind 1). You could make an argument for
inventing *two* new pg_stats columns instead, but I think that is
probably overkill; I doubt it'll be useful to have both MCV and MCELEM
stats for the same column. This could easily be changed though.

I removed the prune step after the last tsvector. I'm not convinced
that the LC algorithm's guarantees still hold if we prune partway
through a bucket, and anyway it's far from clear that we'd save enough
in the sort step to compensate for more HASH_REMOVE operations. I'm
open to being convinced otherwise.

I made some other cosmetic changes, but those were the substantive ones.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[COMMITTERS] pgsql: Create a type-specific typanalyze routine for tsvector, which

Log Message:
-----------
Create a type-specific typanalyze routine for tsvector, which collects stats
on the most common individual lexemes in place of the mostly-useless default
behavior of counting duplicate tsvectors. Future work: create selectivity
estimation functions that actually do something with these stats.

(Some other things we ought to look at doing: using the Lossy Counting
algorithm in compute_minimal_stats, and using the element-counting idea for
stats on regular arrays.)

Jan Urbanski

Modified Files:
--------------
pgsql/doc/src/sgml:
catalogs.sgml (r2.167 -> r2.168)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/catalogs.sgml?r1=2.167&r2=2.168)
pgsql/src/backend/catalog:
system_views.sql (r1.52 -> r1.53)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/system_views.sql?r1=1.52&r2=1.53)
pgsql/src/backend/tsearch:
Makefile (r1.6 -> r1.7)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tsearch/Makefile?r1=1.6&r2=1.7)
pgsql/src/include/catalog:
catversion.h (r1.466 -> r1.467)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.466&r2=1.467)
pg_operator.h (r1.160 -> r1.161)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_operator.h?r1=1.160&r2=1.161)
pg_proc.h (r1.504 -> r1.505)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h?r1=1.504&r2=1.505)
pg_statistic.h (r1.35 -> r1.36)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_statistic.h?r1=1.35&r2=1.36)
pg_type.h (r1.196 -> r1.197)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_type.h?r1=1.196&r2=1.197)
pgsql/src/include/tsearch:
ts_type.h (r1.12 -> r1.13)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/tsearch/ts_type.h?r1=1.12&r2=1.13)
pgsql/src/test/regress/expected:
rules.out (r1.139 -> r1.140)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/rules.out?r1=1.139&r2=1.140)

Added Files:
-----------
pgsql/src/backend/tsearch:
ts_typanalyze.c (r1.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tsearch/ts_typanalyze.c?rev=1.1&content-type=text/x-cvsweb-markup)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[pdxpug] Pg booth staffing at OSCON

OSCON is fast approaching - just one more week!

I need some people to help out with booth staffing for Thursday. Sign up here:
http://wiki.postgresql.org/wiki/Oscon_2008_signup

Staffing the booth is a ton o' fun and a great way to meet people!

Thank you!

gabrielle

PS: Michael - what kind of balloons should I provide for you? :)
--
PDXPUG: http://pugs.postgresql.org/pdx

--
Sent via pdxpug mailing list (pdxpug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pdxpug

[pgsql-advocacy] Reminder - PDXPUG Day

OSCON and PDXPUG Day are just one week away!

PDXPUG Day scheduled speakers:
http://pugs.postgresql.org/view/pdxpugtalksview

Sign up here:
http://spreadsheets.google.com/viewform?key=paoTJ9uEi8vIqumUzwzrCAw&email=true

Please sign up for free admission to the after-party at the Gotham
Tavern, and to reserve a tshirt. We are requesting a $20 donation
that will be given to Software in the Public Interest for attendance.
You can pay with check or cash when you arrive at the conference.

Thank you!

gabrielle
--
PDXPUG: http://pugs.postgresql.org/pdx

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

[COMMITTERS] npgsql - Npgsql2: [#1010425] Patch for actual german translation Added

Log Message:
-----------

[#1010425] Patch for actual german translation

Added missing german localization files and fix VS.Net 2008 project file to use them and previous french localization commited.
Thanks Christian Graefe (christian.graefe @nospam@ web.de) for patch.

Modified Files:
--------------
Npgsql2/src:
Npgsql2008.csproj (r1.13 -> r1.14)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql2008.csproj.diff?r1=1.13&r2=1.14)

Added Files:
-----------
Npgsql2/src/Npgsql:
NpgsqlClosedState.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlClosedState.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
NpgsqlCommandBuilder.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlCommandBuilder.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
NpgsqlConnectedState.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlConnectedState.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
NpgsqlConnectionStringBuilder.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlConnectionStringBuilder.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
NpgsqlException.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlException.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
NpgsqlReadyState.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlReadyState.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
NpgsqlRow.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlRow.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
NpgsqlState.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlState.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
PGUtil.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/PGUtil.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)
Npgsql2/src/NpgsqlTypes:
NpgsqlTypesHelper.de.resx (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/NpgsqlTypes/NpgsqlTypesHelper.de.resx?rev=1.1&content-type=text/x-cvsweb-markup)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] PATCH: CITEXT 2.0 v3

On Jul 13, 2008, at 16:06, David E. Wheeler wrote:

> Should those return bytea and citext, respectively? IOW, are these
> right?
>
> CREATE OR REPLACE FUNCTION citextrecv(bytea)
> RETURNS citext
> AS 'textrecv'
> LANGUAGE 'internal' IMMUTABLE STRICT;
>
> CREATE OR REPLACE FUNCTION citextsend(citext)
> RETURNS bytea
> AS 'textsend'
> LANGUAGE 'internal' IMMUTABLE STRICT;

To judge by the User-Defined Types docs, I was close. :-) I just
changed the argument to citextrecv to "internal".

Thanks,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0 v3

On Jul 13, 2008, at 10:19, Tom Lane wrote:

>> I'm confused. Is that not what the citextin and citextout functions
>> are?
>
> No, those are text I/O. You need analogues of textsend and textrecv
> too.

Should those return bytea and citext, respectively? IOW, are these
right?

CREATE OR REPLACE FUNCTION citextrecv(bytea)
RETURNS citext
AS 'textrecv'
LANGUAGE 'internal' IMMUTABLE STRICT;

CREATE OR REPLACE FUNCTION citextsend(citext)
RETURNS bytea
AS 'textsend'
LANGUAGE 'internal' IMMUTABLE STRICT;

Thanks,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0 v3

On Jul 13, 2008, at 10:19, Tom Lane wrote:

> "David E. Wheeler" <david@kineticode.com> writes:
>> On Jul 12, 2008, at 12:17, Tom Lane wrote:
>>> * You should provide binary I/O (send/receive) functions, if you
>>> want
>>> this to be an industrial-strength module. It's easy since you can
>>> piggyback on text's.
>
>> I'm confused. Is that not what the citextin and citextout functions
>> are?
>
> No, those are text I/O. You need analogues of textsend and textrecv
> too.

Okay.

>> Thanks. Added to my list.
>
> BTW, actually a better idea would be to put citext.sql at the front of
> the list and just run the whole main regression series with it
> present.
> typ_sanity and oidjoins might possibly find issues too.

Also added to my list. :-)

> Some (not all) of your CREATE OPERATOR commands have things like
>
> NEGATOR = OPERATOR(!~),
>
> which seems unnecessary, and is certainly inconsistent.

Oh, I hadn't even noticed those; I'd just copied them from citext 1.
Fixed!

Best,

David


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0 v3

On Jul 13, 2008, at 10:16, Tom Lane wrote:

> Hmm. I think what that actually means is that the cast from citext to
> bpchar should be AS ASSIGNMENT rather than IMPLICIT. What is
> happening
> is that the system can't figure out whether to use length(text) or
> length(bpchar) when presented with a citext argument. I had been
> thinking yesterday that it would automatically prefer length(text)
> because text is a "preferred type", but after tracing through it I see
> that that doesn't happen because citext is not thought to be of the
> string category. (We really need a way to let user-defined types
> specify their category...)

That'd be nice.

> The fact that you need all these piggyback functions is a red flag
> because what it implies is that citext will not work nicely for any
> situation where both text and bpchar functions have been provided
> --- and that includes user-added functions, so it's hopeless to think
> that you can get to a solution this way. Downgrading the cast seems
> like the right thing to me.

Yes, that works for me. I've downgraded it and can now remove the size
functions and all the tests still pass.

> The implicit cast to varchar is a bit worrisome because it creates the
> same issue if someone has provided both varchar and text versions of a
> function. However, that seems a bit pointless given the lack of
> semantic difference, and I suspect that a lot of user-written
> functions
> come only in varchar variants --- so on balance my recommendation is
> to
> keep that one as implicit.

Yes, I agree. Thanks for tracing this out, Tom, it never would have
ocurred to me -- and now I know more than I did before!

Best,

David


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgadmin-support] Support pgAdmin

Bonsoir,

Ali SIRIBIE a écrit :
> Je demande un support sur pgAdmin en français
> Cordialement,
> Ali du Burkina Faso
> Apprenant Ubuntu
>

Ceci une liste de discussion en anglais seulement. Merci d'utiliser
l'anglais dans vos messages. Si vous ne parlez pas anglais,
contactez-moi directement.

De quel type de support avez-vous besoin ?

=====

This is an english only mailing list. Please use english in your
messages. If you don't speak english, contact me directly.

What kind of support do you need ?

Regards.


--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [GENERAL] Users functions library

2008/7/13 Alejandro D. Burne <alejandro.dburne@gmail.com>:
> 2008/7/13 Pavel Stehule <pavel.stehule@gmail.com>:
>> Hello
>>
>> safe it to pgfoundry http://pgfoundry.org/
>> regards
>> Pavel Stehule
>>
>>
>
> May be to much for including in pgfoundry, I think to build a place to
> share code developed in postgres functions (plpgsql, plpython, etc)
> and to categorize them. I can help to develop it, buy my natural
> language is spanish and I'm uncomfortable writing in english.
>
> Greetings, Alejandro
>

you can share code on http://www.pgsql.cz/index.php/PostgreSQL_SQL_Tricks

Regards
Pavel

>
>
>> 2008/7/13 Alejandro D. Burne <alejandro.dburne@gmail.com>:
>>> 2008/7/12 Alejandro D. Burne <alejandro.dburne@gmail.com>:
>>>> Hi, I need to write a function that gives me a password string, no
>>>> just a numbers-characters string; something like people wrote in php,
>>>> its based on determined syllables and numbers.
>>>> I think it be useful to other people, is there a site where one can
>>>> post it and share with other postgres users?
>>>>
>>>> Alejandro
>>>>
>>>
>>> Sorry, the function:
>>>
>>> CREATE OR REPLACE FUNCTION gen_password(plenght smallint)
>>> RETURNS bpchar AS
>>> $BODY$
>>>
>>> DECLARE
>>> lValid_Consonant bpchar DEFAULT 'BCDFGHJKMNPRSTV';
>>> lValid_Vowel bpchar DEFAULT 'AEIOUY';
>>> lValid_Numbers bpchar DEFAULT '23456789';
>>>
>>> lConsonant_Length smallint DEFAULT char_length(lValid_Consonant);
>>> lVowel_Length smallint DEFAULT char_length(lValid_Vowel);
>>> lNumbers_Length smallint DEFAULT char_length(lValid_Numbers);
>>>
>>> lPassword bpchar DEFAULT '';
>>>
>>> BEGIN
>>> LOOP
>>> IF ROUND(RANDOM()*3)<>1 THEN
>>> lPassword:=lPassword||SUBSTRING(lValid_Consonant FROM
>>> (ROUND(RANDOM()*(lConsonant_Length-1))+1)::integer FOR 1)||
>>> SUBSTRING(lValid_Vowel FROM
>>> (ROUND(RANDOM()*(lVowel_Length-1))+1)::integer FOR 1);
>>> IF ROUND(RANDOM()*2)<>1 THEN
>>> lPassword:=lPassword||SUBSTRING(lValid_Consonant FROM
>>> (ROUND(RANDOM()*(lConsonant_Length-1))+1)::integer FOR 1);
>>> END IF;
>>> ELSE
>>> lPassword:=lPassword||SUBSTRING(lValid_Numbers FROM
>>> (ROUND(RANDOM()*(lNumbers_Length-1))+1)::integer FOR 1);
>>> END IF;
>>> IF char_length(lPassword) >= plenght THEN
>>> EXIT;
>>> END IF;
>>> END LOOP;
>>>
>>> RETURN SUBSTRING(lPassword FROM 1 FOR plenght);
>>> END;
>>>
>>> $BODY$
>>> LANGUAGE 'plpgsql' VOLATILE;
>>>
>>> --
>>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-general
>>>
>>
>

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[COMMITTERS] pgsql: Change the PageGetContents() macro to guarantee its result is

Log Message:
-----------
Change the PageGetContents() macro to guarantee its result is maxalign'd,
thereby forestalling any problems with alignment of the data structure placed
there. Since SizeOfPageHeaderData is maxalign'd anyway in 8.3 and HEAD, this
does not actually change anything right now, but it is foreseeable that the
header size will change again someday. I had to fix a couple of places that
were assuming that the content offset is just SizeOfPageHeaderData rather than
MAXALIGN(SizeOfPageHeaderData). Per discussion of Zdenek's page-macros patch.

Modified Files:
--------------
pgsql/src/backend/storage/page:
bufpage.c (r1.79 -> r1.80)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/page/bufpage.c?r1=1.79&r2=1.80)
pgsql/src/include/access:
gin.h (r1.23 -> r1.24)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gin.h?r1=1.23&r2=1.24)
pgsql/src/include/storage:
bufpage.h (r1.81 -> r1.82)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/bufpage.h?r1=1.81&r2=1.82)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] [PATCHES] GIN improvements

Updated: http://www.sigaev.ru/misc/fast_insert_gin-0.9.gz

> need more review of fast_insert yet? It looked like a number of people
> commented on it already.

I still havn't clearness of acceptability for suggested aminsertcleanup calling.


--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[COMMITTERS] pgsql: Clean up the use of some page-header-access macros: principally,

Log Message:
-----------
Clean up the use of some page-header-access macros: principally, use
SizeOfPageHeaderData instead of sizeof(PageHeaderData) in places where that
makes the code clearer, and avoid casting between Page and PageHeader where
possible. Zdenek Kotala, with some additional cleanup by Heikki Linnakangas.

I did not apply the parts of the proposed patch that would have resulted in
slightly changing the on-disk format of hash indexes; it seems to me that's
not a win as long as there's any chance of having in-place upgrade for 8.4.

Modified Files:
--------------
pgsql/src/backend/access/gist:
gistutil.c (r1.29 -> r1.30)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistutil.c?r1=1.29&r2=1.30)
pgsql/src/backend/access/hash:
hashutil.c (r1.55 -> r1.56)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/hash/hashutil.c?r1=1.55&r2=1.56)
pgsql/src/backend/access/heap:
heapam.c (r1.260 -> r1.261)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/heapam.c?r1=1.260&r2=1.261)
hio.c (r1.71 -> r1.72)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/hio.c?r1=1.71&r2=1.72)
pruneheap.c (r1.15 -> r1.16)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/pruneheap.c?r1=1.15&r2=1.16)
pgsql/src/backend/access/nbtree:
nbtpage.c (r1.109 -> r1.110)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtpage.c?r1=1.109&r2=1.110)
pgsql/src/backend/access/transam:
xlog.c (r1.315 -> r1.316)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.315&r2=1.316)
xlogutils.c (r1.56 -> r1.57)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlogutils.c?r1=1.56&r2=1.57)
pgsql/src/backend/commands:
sequence.c (r1.153 -> r1.154)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/sequence.c?r1=1.153&r2=1.154)
trigger.c (r1.234 -> r1.235)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/trigger.c?r1=1.234&r2=1.235)
pgsql/src/backend/optimizer/util:
plancat.c (r1.147 -> r1.148)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/plancat.c?r1=1.147&r2=1.148)
pgsql/src/backend/storage/buffer:
bufmgr.c (r1.233 -> r1.234)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/buffer/bufmgr.c?r1=1.233&r2=1.234)
pgsql/src/include/access:
hash.h (r1.88 -> r1.89)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/hash.h?r1=1.88&r2=1.89)
htup.h (r1.99 -> r1.100)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/htup.h?r1=1.99&r2=1.100)
itup.h (r1.49 -> r1.50)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/itup.h?r1=1.49&r2=1.50)
nbtree.h (r1.120 -> r1.121)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/nbtree.h?r1=1.120&r2=1.121)
tuptoaster.h (r1.40 -> r1.41)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/tuptoaster.h?r1=1.40&r2=1.41)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [GENERAL] Users functions library

2008/7/13 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
> safe it to pgfoundry http://pgfoundry.org/
> regards
> Pavel Stehule
>
>

May be to much for including in pgfoundry, I think to build a place to
share code developed in postgres functions (plpgsql, plpython, etc)
and to categorize them. I can help to develop it, buy my natural
language is spanish and I'm uncomfortable writing in english.

Greetings, Alejandro

> 2008/7/13 Alejandro D. Burne <alejandro.dburne@gmail.com>:
>> 2008/7/12 Alejandro D. Burne <alejandro.dburne@gmail.com>:
>>> Hi, I need to write a function that gives me a password string, no
>>> just a numbers-characters string; something like people wrote in php,
>>> its based on determined syllables and numbers.
>>> I think it be useful to other people, is there a site where one can
>>> post it and share with other postgres users?
>>>
>>> Alejandro
>>>
>>
>> Sorry, the function:
>>
>> CREATE OR REPLACE FUNCTION gen_password(plenght smallint)
>> RETURNS bpchar AS
>> $BODY$
>>
>> DECLARE
>> lValid_Consonant bpchar DEFAULT 'BCDFGHJKMNPRSTV';
>> lValid_Vowel bpchar DEFAULT 'AEIOUY';
>> lValid_Numbers bpchar DEFAULT '23456789';
>>
>> lConsonant_Length smallint DEFAULT char_length(lValid_Consonant);
>> lVowel_Length smallint DEFAULT char_length(lValid_Vowel);
>> lNumbers_Length smallint DEFAULT char_length(lValid_Numbers);
>>
>> lPassword bpchar DEFAULT '';
>>
>> BEGIN
>> LOOP
>> IF ROUND(RANDOM()*3)<>1 THEN
>> lPassword:=lPassword||SUBSTRING(lValid_Consonant FROM
>> (ROUND(RANDOM()*(lConsonant_Length-1))+1)::integer FOR 1)||
>> SUBSTRING(lValid_Vowel FROM
>> (ROUND(RANDOM()*(lVowel_Length-1))+1)::integer FOR 1);
>> IF ROUND(RANDOM()*2)<>1 THEN
>> lPassword:=lPassword||SUBSTRING(lValid_Consonant FROM
>> (ROUND(RANDOM()*(lConsonant_Length-1))+1)::integer FOR 1);
>> END IF;
>> ELSE
>> lPassword:=lPassword||SUBSTRING(lValid_Numbers FROM
>> (ROUND(RANDOM()*(lNumbers_Length-1))+1)::integer FOR 1);
>> END IF;
>> IF char_length(lPassword) >= plenght THEN
>> EXIT;
>> END IF;
>> END LOOP;
>>
>> RETURN SUBSTRING(lPassword FROM 1 FOR plenght);
>> END;
>>
>> $BODY$
>> LANGUAGE 'plpgsql' VOLATILE;
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[pgadmin-support] Support pgAdmin

Bonjour
Je demande un support sur pgAdmin en français
Cordialement,
Ali du Burkina Faso
Apprenant Ubuntu


Envoyé avec Yahoo! Mail.
Une boite mail plus intelligente.

Re: [PATCHES] page macros cleanup (ver 04)

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> ... That macro is actually doing the
> same thing as PageGetContents, so I switched to using that. As that
> moves the data sligthly on those bitmap pages, I guess we'll need a
> catversion bump.

I'm amazed that Zdenek didn't scream bloody murder about that. You're
creating a work item for in-place-upgrade that would not otherwise
exist, in exchange for a completely trivial bit of code beautification.
(The same can be said of his proposed change to hash meta pages.)

I'm planning to go over this patch today and apply it sans the parts
that would require catversion bump. We can argue later about whether
those are really worth doing, but I'm leaning to "not" --- unless Zdenek
says that he has no intention of making in-place-upgrade handle hash
indexes any time soon.

BTW, after further thought about the PageGetContents() situation:
right now we can change it to guarantee maxalignment "for free",
since SizeOfPageHeaderData happens to be maxaligned on all platforms
(this wasn't the case as recently as 8.2). So I'm thinking we should
do that. There's at least one place that thinks that PageGetContents
is the same as page + SizeOfPageHeaderData, but that's easily fixed.
On balance it seems like hidden assumptions about alignment are a bigger
risk than assumptions about that offset --- anyone want to argue the
contrary?

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] page macros cleanup (ver 04)

Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Good catch. if we have to bump catalog version then I have there small patch
> which introduce following macro and remove PageHeaderData stucture from
> HashMetaPageData:

Seems like a bad idea --- PageGetContents is not guaranteed to deliver
a maxaligned pointer, so at least in principle this could result in
alignment violations. It would accidentally fail to fail as of CVS
HEAD, but any future rearrangement of PageHeaderData or HashMetaPageData
could create a problem.

(Possibly PageGetContents *should* guarantee a maxaligned result,
but the current coding does not.)

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [HACKERS] PATCH: CITEXT 2.0 v3

"David E. Wheeler" <david@kineticode.com> writes:
> On Jul 12, 2008, at 14:57, Tom Lane wrote:
>> Sadly, I think you have to give up
>> attempts to check the interesting multibyte cases and confine yourself
>> to tests using ASCII strings.

> Grr. Kind of defeats the purpose. Is there no infrastructure for
> testing multibyte functionality?

There's some stuff under src/test/locale and src/test/mb, though it
doesn't get exercised regularly. The contrib tests are a particularly
bad place for trying to do any locale-dependent testing, because we
only support "make installcheck" which means there is no way to set
the database locale --- you *have to* work with whatever locale is
predetermined by the postmaster you're pointed at.

I don't recall the reason for not supporting "make check" in the contrib
modules; maybe it was just that preparing a test installation for each
contrib module sounded too slow? In any case, what you'd need to pursue
is having some additional tests available that are not executed by the
standard contrib regression test sequence.

(If we get to having per-database collations in 8.4 then integrating a
test with a non-default collation would get a lot easier, of course;
but for the moment I'm afraid you've got to work with what's there.)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-fr-generale] table temporaire ou raz

Bonjour,

William Dode a écrit :
> Pour faciliter les éditions j'utilise des tables intermédiaires, je me
> demande toujours s'il vaut mieux remettre à zéro une table existante ou
> la recréer à chaque fois en TEMP ?
> Sachant que plusieurs personnes vont peut-être demander une édition en
> même temps et donc que ça se déroule systématiquement dans une
> transaction.
>
> A priori j'imagine qu'il vaudrait mieux utiliser une table temporaire
> (qu'elles sont faites pour ça), mais je ne le fait pas systématiquement
> car ça rend plus difficile le debugage.
>
> Des avis ?
>

Une table temporaire a une bonne chance de ne se trouver qu'en mémoire,
surtout avec un temp_buffers bien configuré. Une "vraie" table sera
systématiquement sur disque. Donc, pour des raisons de performances,
j'aurais tendance à privilégier la création de tables temporaires.
Surtout dans votre cas où vous serez dans une seule et même transaction.

Je comprends bien le soucis que cela pose pour le débuggage. Néanmoins,
les avantages (en terme de performance, donc pour les utilisateurs)
dépassent de loin les inconvénients (en terme de facilité, pour les
développeurs).


--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

Re: [HACKERS] PATCH: CITEXT 2.0 v3

"David E. Wheeler" <david@kineticode.com> writes:
> On Jul 12, 2008, at 12:17, Tom Lane wrote:
>> * You should provide binary I/O (send/receive) functions, if you want
>> this to be an industrial-strength module. It's easy since you can
>> piggyback on text's.

> I'm confused. Is that not what the citextin and citextout functions are?

No, those are text I/O. You need analogues of textsend and textrecv
too.

>> You might try running the
>> opr_sanity regression test on this module to see if it finds any
>> other silliness. (Procedure: insert the citext definition script
>> into the serial_schedule list just ahead of opr_sanity, run tests,
>> make sure you understand the reason for any diffs in the opr_sanity
>> result. There will be at least one from the uses of text-related
>> functions for citext.)

> Thanks. Added to my list.

BTW, actually a better idea would be to put citext.sql at the front of
the list and just run the whole main regression series with it present.
typ_sanity and oidjoins might possibly find issues too.

>> * Don't use the OPERATOR() notation when you don't need to.
>> It's just clutter.

> Sorry, don't know what you're referring to here.

Some (not all) of your CREATE OPERATOR commands have things like

NEGATOR = OPERATOR(!~),

which seems unnecessary, and is certainly inconsistent.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0 v3

"David E. Wheeler" <david@kineticode.com> writes:
> When I deleted any of the others, I got errors like this:

> psql:sql/citext.sql:865: ERROR: function length(citext) is not unique
> LINE 1: SELECT is( length( name ), length(name::text), 'length("' ||...
> ^
> HINT: Could not choose a best candidate function. You might need to
> add explicit type casts.

Hmm. I think what that actually means is that the cast from citext to
bpchar should be AS ASSIGNMENT rather than IMPLICIT. What is happening
is that the system can't figure out whether to use length(text) or
length(bpchar) when presented with a citext argument. I had been
thinking yesterday that it would automatically prefer length(text)
because text is a "preferred type", but after tracing through it I see
that that doesn't happen because citext is not thought to be of the
string category. (We really need a way to let user-defined types
specify their category...)

The fact that you need all these piggyback functions is a red flag
because what it implies is that citext will not work nicely for any
situation where both text and bpchar functions have been provided
--- and that includes user-added functions, so it's hopeless to think
that you can get to a solution this way. Downgrading the cast seems
like the right thing to me.

The implicit cast to varchar is a bit worrisome because it creates the
same issue if someone has provided both varchar and text versions of a
function. However, that seems a bit pointless given the lack of
semantic difference, and I suspect that a lot of user-written functions
come only in varchar variants --- so on balance my recommendation is to
keep that one as implicit.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-fr-generale] table temporaire ou raz

slt,

Pour faciliter les éditions j'utilise des tables intermédiaires, je me
demande toujours s'il vaut mieux remettre à zéro une table existante ou
la recréer à chaque fois en TEMP ?
Sachant que plusieurs personnes vont peut-être demander une édition en
même temps et donc que ça se déroule systématiquement dans une
transaction.

A priori j'imagine qu'il vaudrait mieux utiliser une table temporaire
(qu'elles sont faites pour ça), mais je ne le fait pas systématiquement
car ça rend plus difficile le debugage.

Des avis ?

--
William Dodé -

http://flibuste.net
Informaticien indépendant


--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

Re: [HACKERS] COPY command, support for mixing binary and text columns?

"Stephen R. van den Berg" <srb@cuci.nl> writes:
> Am I correct in the assumption that even though the network protocol
> specifically allows individual columns of a copy command to be
> binary or text format, the current COPY command in 8.3 doesn't
> support specifying that?

Yeah, the protocol is a bit more general than the actual file format.
The text COPY format really couldn't support mixed text and binary
fields at all, of course; and as for the binary format, the COPY
reference page says:

: Presently, all data values in a COPY BINARY file are assumed to be in
: binary format (format code one). It is anticipated that a future
: extension might add a header field that allows per-column format codes
: to be specified.

But it's been like that since PG 7.4, and no one's gotten motivated
to complete the feature, so don't hold your breath ;-)

AFAIK there are no client libraries that actually pay any attention to
the protocol's format codes anyway --- they just push the COPY data
through uninterpreted.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PATCHES] variadic function support

"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> 2008/7/13 Jeff Davis <pgsql@j-davis.com>:
>> Also, it doesn't seem to allow calls to a variadic function with zero
>> arguments, e.g. "mleast()". I think this should be allowed.

> It's not possible for all cases, because empty array have be typed
> array still. But for non polymorphic variadic functions it's probably
> possible - I would to solve this question later - and for now use
> overloading etc

I don't really like the idea of a feature that would work except in the
polymorphic case --- that just seems too non-orthogonal. Also I tend
to think that a pretty large fraction of variadic functions will be
polymorphic, making the feature's usefulness even more dubious.

I concur with the idea that variadic functions should only match to
calls that offer at least one value for the variadic array. If you can
actually define the behavior sensibly for the zero-element case, a
separate function of the same name can cover that case.

As far as the "variadic int" versus "variadic int[]" business, I'm
starting to agree with Pavel that "variadic int[]" offers less potential
for confusion. In particular, it seems to make it more obvious for the
function author that the argument he receives is an array. Also, the
other one would mean that what we put into pg_proc.proargtypes doesn't
agree directly with what the user thinks the argument types are. While
I think we could force that to work, it's not exactly satisfying the
principle of least surprise.


One issue that just occurred to me: what if a variadic function wants to
turn around and call another variadic function, passing the same array
argument on to the second one? This is closely akin to the problem
faced by C "..." functions, and the solutions are pretty ugly (sprintf
vs vsprintf for instance). Can we do any better? At least in the
polymorphic case, I'm not sure we can :-(.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[HACKERS] COPY command, support for mixing binary and text columns?

Am I correct in the assumption that even though the network protocol
specifically allows individual columns of a copy command to be
binary or text format, the current COPY command in 8.3 doesn't
support specifying that?

Am I missing something in the network protocol which allows me
to specify it regardless of what the COPY command says?
--
Sincerely,
Stephen R. van den Berg.

In this signature, the concluding three words `were left out'.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Protocol 3, Execute, maxrows to return, impact?

Gregory Stark wrote:
>"Abhijit Menon-Sen" <ams@oryx.com> writes:
>>> Interleaved retrieval using multiple portals is not what most
>>> libraries support, I'd guess.

>> My code did support that mode of operation in theory, but in practice
>> in the few situations where I have needed to use something like it, I
>> found it more convenient to open explicit cursors and FETCH from them

>Note that using FETCH for each record means a round trip to the server for
>each record. If you're dealing with a lot of records that could be a lot
>slower than streaming them to the client as quickly as it can consume them.

>Now I'm not sure anyone's actually done any experiments to optimize libpq or
>other drivers to stream data efficiently, so I'm not sure how much you would
>really lose in practice today.

My Pike drivers now support multiple simultaneous portals and
automatic streaming by presending overlapping Execute statements with
a dynamically adapted fetchlimit calculated per select as the query
progresses.

The only support still lacking is COPY.
--
Sincerely,
Stephen R. van den Berg.

In this signature, the concluding three words `were left out'.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [INTERFACES] connecting with libpq interface

Hi,

Vincent Predoehl wrote:
>>> terminate called after throwing an instance of 'pqxx::broken_connection'
>>> what(): could not connect to server: No such file or directory
>>> Is the server running locally and accepting
>>> connections on Unix domain socket "/var/run/
>>> postgresql/.s.PGSQL.5432"?
>>
>> PQerrorMessage() should give you the same info in your standalone
>> libpq program.
>
> Yes it does:
>
> could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket
> "/var/run/postgresql/.s.PGSQL.5432"?

Something similar has biten me before as well. I figured it is the
Debian packager's decision to put those socket files under
/var/run/postgresql/, which is not the Postgres standard.

Regards

Markus


--
Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-interfaces