Sunday, June 15, 2008

Re: [GENERAL] How to INSERT empty line into SEQUENTIAL table from PHP

Hi, Stefan.

your second example should work for you.
INSERT INTO table_xx (field2, field3, field4) VALUES ('', '', '');
(keeping in mind, that your ID column is of type serial or has DEFAULT
NEXTVAL('some_sequence') ).
You can also insert values yourself:
INSERT INTO table_xx (ID, field2, field3, field4) VALUES
(NEXTVAL('some_sequence'), '', '', '');

Julius Tuskenis

Stefan Schwarzer rašė:
> Hi,
>
> rahter dump question, I guess....
>
> But I have a table with a sequential index field, into which I would
> like to add from time to time another line (via webbrowser), which in
> turn, stays first empty, before it's being filled in later (via
> webbrowser).
>
> Because the ID field is sequential and indexed, I can't use
>
> INSERT INTO table_xx (ID, field2, field3, field4) VALUES ('', '',
> '', '');
>
> neither (skipping ID because it should be filled in automatically):
>
> INSERT INTO table_xx (field2, field3, field4) VALUES ('', '', '');
>
> How am I supposed to do it?
>
> Thanks for any hints,
>
> Stef
>
>

--
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] How to INSERT empty line into SEQUENTIAL table from PHP

am Mon, dem 16.06.2008, um 8:33:27 +0200 mailte Stefan Schwarzer folgendes:
> Hi,
>
> rahter dump question, I guess....
>
> But I have a table with a sequential index field, into which I would
> like to add from time to time another line (via webbrowser), which in
> turn, stays first empty, before it's being filled in later (via
> webbrowser).
>
> Because the ID field is sequential and indexed, I can't use
>
> INSERT INTO table_xx (ID, field2, field3, field4) VALUES ('', '',
> '', '');
>
> neither (skipping ID because it should be filled in automatically):
>
> INSERT INTO table_xx (field2, field3, field4) VALUES ('', '', '');

insert into table_xx (id, field2, ...) values (NULL, ...)


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-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [SQL] Results with leading zero

Perfect!
Thank you very mcuh :)

2008/6/16 A. Kretschmer <andreas.kretschmer@schollglas.com>:
> am Mon, dem 16.06.2008, um 11:48:01 +1000 mailte novice folgendes:
>> I have a table
>>
>> CREATE TABLE problem (
>> problem_id integer,
>> solution_count integer
>> );
>>
>> INSERT INTO problem VALUES (1001, 4);
>> INSERT INTO problem VALUES (1012, 11);
>>
>> SELECT * from problem;
>>
>> problem_id | solution_count
>> ------------+---------------
>> 1001 | 4
>> 1012 | 11
>> (2 rows)
>>
>>
>> Is there a way I could write a query to produce the following? I will
>> need the leading zero for solution < 10
>>
>> problem_id | solution
>> -------------+------------
>> 1001 | 01
>> 1001 | 02
>
> My previous answer was a little bit wrong (no leading zero for solution
> < 10), sorry. But no problem:
>
> select problem_id, to_char(generate_Series(1,solution_count),'09') as solution_count from problem ;
>
>
>
> 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
>

--
THINK BEFORE YOU PRINT - Save paper if you don't really need to print this.

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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

On Mon, Jun 16, 2008 at 02:12:03AM -0300, Marc G. Fournier wrote:
> Actually, I had updated it last release, apparently, for some reason, the
> update was rejected ... I just re-updated for 8.3.3, and it went through fine
> ... don't believe I did anything different with the last release then I've ever
> done, or did this last time *shrug*

This doesn't address the need to have more people than just you with
that access.

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

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

[GENERAL] How to INSERT empty line into SEQUENTIAL table from PHP

Hi,

rahter dump question, I guess....

But I have a table with a sequential index field, into which I would
like to add from time to time another line (via webbrowser), which in
turn, stays first empty, before it's being filled in later (via
webbrowser).

Because the ID field is sequential and indexed, I can't use

INSERT INTO table_xx (ID, field2, field3, field4) VALUES ('', '', '',
'');

neither (skipping ID because it should be filled in automatically):

INSERT INTO table_xx (field2, field3, field4) VALUES ('', '', '');

How am I supposed to do it?

Thanks for any hints,

Stef


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

Re: [SQL] Results with leading zero

am Mon, dem 16.06.2008, um 11:48:01 +1000 mailte novice folgendes:
> I have a table
>
> CREATE TABLE problem (
> problem_id integer,
> solution_count integer
> );
>
> INSERT INTO problem VALUES (1001, 4);
> INSERT INTO problem VALUES (1012, 11);
>
> SELECT * from problem;
>
> problem_id | solution_count
> ------------+---------------
> 1001 | 4
> 1012 | 11
> (2 rows)
>
>
> Is there a way I could write a query to produce the following? I will
> need the leading zero for solution < 10
>
> problem_id | solution
> -------------+------------
> 1001 | 01
> 1001 | 02

My previous answer was a little bit wrong (no leading zero for solution
< 10), sorry. But no problem:

select problem_id, to_char(generate_Series(1,solution_count),'09') as solution_count from problem ;

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

Fwd: [pgsql-it-generale] to_tsvector: errori nella configurazione italiana

Mi sono dimenticato di postarlo alla mailing list. Scusate…

Begin forwarded message:

> From: Giorgio Valoti <giorgio_v@mac.com>
> Date: 13 giugno 2008 14:18:33 GMT+02:00
> To: rotellaro@gmail.com
> Subject: Re: [pgsql-it-generale] to_tsvector: errori nella
> configurazione italiana
>
>
> On 13/giu/08, at 12:08, rotellaro@gmail.com wrote:
>
>>>
>>> […]
>>
>> mmmmmmmmmmmmmmmmmmmmmmmmmmmm
>> posteresti l'output di pg_controlfile?
>
> Parli di pg_controldata? Eccolo:
>
>> pg_control version number: 833
>> Catalog version number: 200711281
>> Database system identifier: 5151280585137659751
>> Database cluster state: in production
>> pg_control last modified: Fri Jun 13 11:36:03 2008
>> Latest checkpoint location: 0/25DF37AC
>> Prior checkpoint location: 0/25DD62AC
>> Latest checkpoint's REDO location: 0/25DF37AC
>> Latest checkpoint's TimeLineID: 1
>> Latest checkpoint's NextXID: 0/665551
>> Latest checkpoint's NextOID: 36190
>> Latest checkpoint's NextMultiXactId: 1
>> Latest checkpoint's NextMultiOffset: 0
>> Time of latest checkpoint: Fri Jun 13 11:35:58 2008
>> Minimum recovery ending location: 0/0
>> Maximum data alignment: 4
>> Database block size: 8192
>> Blocks per segment of large relation: 131072
>> WAL block size: 8192
>> Bytes per WAL segment: 16777216
>> Maximum length of identifiers: 64
>> Maximum columns in an index: 32
>> Maximum size of a TOAST chunk: 2000
>> Date/time type storage: 64-bit integers
>> Maximum length of locale name: 128
>> LC_COLLATE: it_IT.UTF-8
>> LC_CTYPE: it_IT.UTF-8
>
>
> Ciao
> --
> Giorgio Valoti
>
>
>


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

Re: [SQL] Results with leading zero

am Mon, dem 16.06.2008, um 11:48:01 +1000 mailte novice folgendes:
> I have a table
>
> CREATE TABLE problem (
> problem_id integer,
> solution_count integer
> );
>
> INSERT INTO problem VALUES (1001, 4);
> INSERT INTO problem VALUES (1012, 11);
>
> SELECT * from problem;
>
> problem_id | solution_count
> ------------+---------------
> 1001 | 4
> 1012 | 11
> (2 rows)
>
>
> Is there a way I could write a query to produce the following? I will


Sure:
select problem_id, generate_Series(1,solution_count) as solution_count from problem ;


Regards, 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

Re: [HACKERS] pltcl broken on tcl8.5 ?

Devrim GÜNDÜZ wrote:
> Hi,
>
> On Sun, 2008-06-15 at 20:54 -0400, Andrew Dunstan wrote:
>
>> Has anyone been able to get the tests to pass using Tcl 8.5.1?
>>
>
> All regression tests passed on Fedora-9 while building new RPM sets.
>
>
>

Do you specifically run the PL regression tests?

cheers

andrew


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

Re: [lapug] June blog

> Visit the Los Angles PostgreSQL Users Group (LAPUG)
> http://pugs.postgresql.org/lapug

Richard,

Nice work keeping the blog updated!

I think to be consistent with most blogs, the order of the content or
nodes should be reversed so that the latest item is at the top. Currently,
you have to scroll down to the bottom of the growing page to see the
latest entry.

Regards,
-Noel

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

Re: [SQL] Results with leading zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIVffl00wYKhpVgQgRAimnAJ9J2nRL4EShvEqqypN4pyb044dU3QCfWNtF
3wdgWM+IdU1KGMlGDOyoqmI=
=XWaq
-----END PGP SIGNATURE-----
Am Mon, 16 Jun 2008 11:48:01 +1000
schrieb novice <user.postgresql@gmail.com>:

You are watching for the lpad() function ...

> I have a table
>
> CREATE TABLE problem (
> problem_id integer,
> solution_count integer
> );
>
> INSERT INTO problem VALUES (1001, 4);
> INSERT INTO problem VALUES (1012, 11);
>
> SELECT * from problem;
>
> problem_id | solution_count
> ------------+---------------
> 1001 | 4
> 1012 | 11
> (2 rows)
>
>
> Is there a way I could write a query to produce the following? I will
> need the leading zero for solution < 10
>
> problem_id | solution
> -------------+------------
> 1001 | 01
> 1001 | 02
> 1001 | 02
> 1001 | 04
> 1012 | 01
> 1012 | 02
> 1012 | 03
> 1012 | 04
> 1012 | 05
> 1012 | 06
> 1012 | 07
> 1012 | 08
> 1012 | 09
> 1012 | 10
> 1012 | 11
> (15 rows)
>
> Thanks.
>

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Is there a way of removing 'branches'? Or do we want to list all the old
versions that we are still supporting? Can you have 'multiple stable'?

- --On Friday, June 13, 2008 15:10:18 +0930 Shane Ambler <pgsql@Sheeky.Biz>
wrote:

> Bruce Momjian wrote:
>> Josh Berkus wrote:
>>> Check it out, folks:
>>>
>>> http://freshmeat.net/
>>
>> And Freshmeat has 8.3.0! I thought we were going to keep this up to
>> date, and if not, we were going to remove it. Well, we are not keeping
>> it up to date!
>>
>> Updated: Wed, Mar 5th 2008 22:40 UTC (3 months, 10 days ago)
>>
> Actually it seems quite messy.
>
> The download links for the tarball etc point to 8.3.0
>
> The branches listed have Dev as 8.0.0rc1 and stable as 8.2.4
>
>
>
>
> --
>
> Shane Ambler
> pgSQL (at) Sheeky (dot) Biz
>
> Get Sheeky @ http://Sheeky.Biz
>
> --
> Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkhV95YACgkQ4QvfyHIvDvNFsQCgini+yJQ/dDTx3J5DsHAQyFte
l8YAoNPBu9JkrMJQgDrDNeOAPbOVsEsQ
=P7qT
-----END PGP SIGNATURE-----


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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Thursday, June 12, 2008 22:36:40 -0400 Bruce Momjian <bruce@momjian.us>
wrote:

> Josh Berkus wrote:
>> Check it out, folks:
>>
>> http://freshmeat.net/
>
> And Freshmeat has 8.3.0! I thought we were going to keep this up to
> date, and if not, we were going to remove it. Well, we are not keeping
> it up to date!

Actually, I had updated it last release, apparently, for some reason, the
update was rejected ... I just re-updated for 8.3.3, and it went through fine
... don't believe I did anything different with the last release then I've ever
done, or did this last time *shrug*

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkhV9iMACgkQ4QvfyHIvDvNBLwCfcclZj3nbT0TUUlLQPSFhNk+9
SvQAnRAc/yZWLcmKyOlnRCOTJb4mYRqS
=9/rV
-----END PGP SIGNATURE-----


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

[HACKERS] Question about Encoding a Custom Type

Howdy,

Possibly showing my ignorance here, but as I'm working on updating
citext to be locale-aware and to work on 8.3, I've run into this
peculiarity:

try=# \encoding
UTF8
try=# select setting from pg_settings where name = 'lc_collate';
setting
-------------
en_US.UTF-8
(1 row)

try=# create table try (name citext);
try=# insert into try (name) values ('aardvark'), ('AAA');
try=# select name, name = 'aaa' from try;
name | ?column?
----------+----------
aardvark | f
AAA | t
(2 rows)

try=# insert into try (name) values ('aba'), ('ABC'), ('abc');
try=# select name, name = 'aaa' from try;
name | ?column?
----------+----------
aardvark | f
AAA | t
aba | f
ABC | f
abc | f
(5 rows)

try=# insert into try (name) values ('AAAA');
try=# select name, name = 'aaa' from try;
ERROR: invalid byte sequence for encoding "UTF8": 0xf6bd
HINT: This error can also happen if the byte sequence does not match
the encoding expected by the server, which is controlled by
"client_encoding".

I've no idea what could be different about 'AAAA' vs. any other value.
And if I do either of these:

select name, name = 'aaa'::text from try;
select name, name::text = 'aaa' from try;

It just works. I'm mystified.

My casts:

CREATE CAST (citext AS text) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (citext AS varchar) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (citext AS bpchar) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (text AS citext) WITHOUT FUNCTION AS ASSIGNMENT;
CREATE CAST (varchar AS citext) WITHOUT FUNCTION AS ASSIGNMENT;
CREATE CAST (bpchar AS citext) WITHOUT FUNCTION AS ASSIGNMENT;

Question about the code? It's all here (for now):

https://svn.kineticode.com/citext/trunk/

Hrm. Fiddling a bit more, I find that this fails, too:

try=# select citext_smaller( 'aardvark'::citext,
'AARDVARKasdfasdfasdfasdf'::citext );
ERROR: invalid byte sequence for encoding "UTF8": 0xc102
HINT: This error can also happen if the byte sequence does not match
the encoding expected by the server, which is controlled by
"client_encoding".

So I guess that something must be up with citext_smaller(). It's quite
simple, though:

PG_FUNCTION_INFO_V1(citext_smaller);

Datum citext_smaller (PG_FUNCTION_ARGS) {
text * left = PG_GETARG_TEXT_P(0);
text * right = PG_GETARG_TEXT_P(1);
PG_RETURN_TEXT_P( citextcmp( PG_ARGS ) < 0 ? left : right );
}

Context:

https://svn.kineticode.com/citext/trunk/citext.c

Anyone have any idea? Feedback would be *most* appreciated.

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] pltcl broken on tcl8.5 ?

Hi,

On Sun, 2008-06-15 at 20:54 -0400, Andrew Dunstan wrote:
> Has anyone been able to get the tests to pass using Tcl 8.5.1?

All regression tests passed on Fedora-9 while building new RPM sets.

Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Re: [pgsql-advocacy] Problem with press release

On Sun, Jun 15, 2008 at 07:25:00PM -0700, Josh Berkus wrote:
>
> I'm disputing Bruce's report that there *are* any.

Well, this is what mutt thinks your MIME encoding is on the message I
got:

text/plain, 8bit, iso-8859-1

Probably the issue is not just that it's not ASCII, but that it's not
UTF-8 either.

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

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

[ANNOUNCE] == PostgreSQL Weekly News - June 15 2008 ==

== PostgreSQL Weekly News - June 15 2008 ==

PostgreSQL 8.3.3, 8.2.9, etc. have been released. Upgrade as soon as
practical.

== PostgreSQL Product News ==

check_postgres 1.8.2 released.
http://bucardo.org/check_postgres/

== PostgreSQL Jobs for June ==

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

== PostgreSQL Local ==

pgDay San Francisco needs presentations for August 5. Submit by June 17th.
http://pugs.postgresql.org/node/415

TorontoPUG's first meeting will be June 23 at The Rhino.
http://pugs.postgresql.org/blog/159

OKPUG's first meeting will be June 23 at 7:00pm at Coach's in Norman, OK.
http://pugs.postgresql.org/node/408

PgDay.IT's planning meeting will be Wednesday, June 25 at 2130 CET via IRC.
irc://irc.freenode.net/pgday-it

pgDay Portland needs presentations for July 20. Submit by 20th.
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 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 ==

Tom Lane committed:

- In pgsql/src/backend/commands/aggregatecmds.c, ALTER AGGREGATE OWNER
seems to have been missed by the last couple of patches that dealt
with object ownership. It wasn't updating pg_shdepend nor adjusting
the aggregate's ACL. In 8.2 and up, fix this permanently by making
it use AlterFunctionOwner_oid. In 8.1, the function code wasn't
factored that way, so just copy and paste.

- In pgsql/doc/src/sgml/release.sgml, update release notes for ALTER
AGGREGATE fix.

- Stamp 8.3.3, 8.2.9, 8.1.13, 8.0.17, 7.4.21 (except for
configure.in/configure).

- Rewrite DROP's dependency traversal algorithm into an honest
two-pass algorithm, replacing the original intention of a one-pass
search, which had been hacked up over time to be partially two-pass
in hopes of handling various corner cases better. It still wasn't
quite there, especially as regards emitting unwanted NOTICE
messages. More importantly, this approach lets us fix a number of
open bugs concerning concurrent DROP scenarios, because we can take
locks during the first pass and avoid traversing to dependent
objects that were just deleted by someone else. There is more that
can be done here, but I'll go ahead and commit the base patch before
working on the options.

- In pgsql/src/backend/access/index/genam.c, fix breakage caused by
conflicting patches, as evidenced by the buildfarm.

- Tag 8.0.17, 7.4.21.

- Fix an ALTER TABLE test case so that it actually tests what the
comment says it is testing. Ah, the perils of making keywords
optional ...

- Fix datetime input functions to correctly detect integer overflow
when running on a 64-bit platform ... strtol() will happily return
64-bit output in that case. Per bug #4231 from Geoff Tolley.

- In pgsql/src/backend/utils/adt/cash.c, fix unportable (and incorrect
anyway) usage of LL constant suffix that recently snuck into cash.c.
Per report from Edmundo Robles Lopez.

- Create a script to handle stamping release version numbers into
files, replacing the tedious and error-prone manual process we've
been using.

- Improve reporting of dependencies in DROP to work like the scheme
that we devised for pg_shdepend, namely the individual dependencies
are reported as DETAIL lines rather than coming out as separate
NOTICEs. The client-side report is capped at 100 lines, but the
server log always gets a full report.

- In pgsql/src/backend/access/heap/tuptoaster.c, improve the various
elog messages in tuptoaster.c to report which TOAST table the
problem happened in. These are all supposedly can't-happen cases,
but when they do happen it's useful to know where. Back-patch to
8.3, but not further because the patch doesn't apply cleanly further
back. Given the lack of response to my proposal of this, there
doesn't seem to be enough interest to justify much back-porting
effort.

- Refactor the handling of the various DropStmt variants so that when
multiple objects are specified, we drop them all in a single
performMultipleDeletions call. This makes the RESTRICT/CASCADE
checks more relaxed: it's not counted as a cascade if one of the
later objects has a dependency on an earlier one. NOTICE messages
about such cases go away, too. In passing, fix the permissions
check for DROP CONVERSION, which for some reason was never made
role-aware, and omitted the namespace-owner exemption too. Alex
Hunsaker, with further fiddling by me.

- Rearrange ALTER TABLE syntax processing as per my recent proposal:
the grammar allows ALTER TABLE/INDEX/SEQUENCE/VIEW interchangeably
for all subforms of those commands, and then we sort out what's
really legal at execution time. This allows the ALTER SEQUENCE/VIEW
reference pages to fully document all the ALTER forms available for
sequences and views respectively, and eliminates a longstanding
cause of confusion for users. The net effect is that the following
forms are allowed that weren't before: ALTER SEQUENCE OWNER TO,
ALTER VIEW ALTER COLUMN SET/DROP DEFAULT, ALTER VIEW OWNER TO, and
ALTER VIEW SET SCHEMA, (There's no actual functionality gain here,
but formerly you had to say ALTER TABLE instead.) Interestingly, the
grammar tables actually get smaller, probably because there are
fewer special cases to keep track of. I did not disallow using
ALTER TABLE for these operations. Perhaps we should, but there's a
backwards-compatibility issue if we do; in fact it would break
existing pg_dump scripts. I did however tighten up ALTER SEQUENCE
and ALTER VIEW to reject non-sequences and non-views in the new
cases as well as a couple of cases where they didn't before. The
patch doesn't change pg_dump to use the new syntaxes, either.

- In pgsql/src/backend/access/gist/gistutil.c, fix 64-bit problem in
recent patch.

- In pgsql/src/backend/commands/tablecmds.c, make DROP INDEX lock the
parent table before locking the index. This behavior is necessary
to avoid deadlock against ordinary queries, but we'd broken it with
recent changes that made the DROP machinery lock the index before
arriving at index_drop. Per intermittent buildfarm failures.

- In pgsql/doc/src/sgml/maintenance.sgml, rewrite docs section about
routine vacuuming --- it's gotten rather mangled of late, with lots
of redundancy, bad grammar, and just plain poor exposition. Make it
clear that autovacuum is now considered the normal solution.

Alvaro Herrera committed:

- Move BufferGetPageSize and BufferGetPage from bufpage.h to bufmgr.h.
It is more logical that way, and also it reduces the amount of
unnecessary includes in bufpage.h, which is widely used. Zdenek
Kotala. My previous patch to bufpage.h should also have credited
him as author, but I forgot (sorry about that).

- In pgsql/doc/src/sgml/Makefile, make XML building work silently on
VPATH builds (untested on regular builds).

- In pgsql/doc/src/sgml/config.sgml, in the log_filename
documentation, mention that strftime is not used directly to expand
the pattern specifier. Per gripe from Josh Drake.

Marc Fournier committed:

- Tag 8.3.3, 8.2.9, 8.1.13.

Neil Conway committed:

- In pgsql/src/backend/storage/lmgr/proc.c, fix typo in comment.

- In pgsql/src/backend/storage/lmgr/proc.c, further tweak for comment
in CheckDeadLock(), per Tom Lane.

- In pgsql/src/bin/psql/mainloop.c, editorialization for the text
emitted by the "help" psql command. Basically just reuse the same
text that psql emitted as part of its startup banner in prior
versions, and make some whitespace more consistent with the
conventions in other psql command output.

Bruce Momjian committed:

- Update Japanese FAQ. Jun Kuwamura.

- In pgsql/src/backend/utils/misc/postgresql.conf.sample, fix spelling
mistake in postgresql.conf. Greg Sabino Mullane.

- Add to TODO: "Add pg_ctl option to do a syntax check of
postgresql.conf."

- In pgsql/doc/src/sgml/ecpg.sgml, use macro to document size of ecpg
sqlerrmc string.

- Update item to mention target list problem.

- Modify TODO entry to be a function: "Add functions to syntax check
configuration files."

Heikki Linnakangas committed:

- In pgsql/src/include/tsearch/ts_type.h, comment fix, should say
TSQuery instead of TSVector. Per Jan Urbanski.

- In pgsql/src/backend/access/nbtree/nbtinsert.c, fix bug in the WAL
recovery code to finish an incomplete split.
CacheInvalidateRelcache() crashes if called in WAL recovery, because
the invalidation infrastructure hasn't been initialized yet.
Back-patch to 8.2, where the bug was introduced.

- Add optional on/off argument to \timing. David Fetter.

- In pgsql/src/bin/psql/help.c, update "help" output to reflect that
\timing now takes an optional on/off argument.

- Refactor XLogOpenRelation() and XLogReadBuffer() in preparation for
relation forks. XLogOpenRelation() and the associated light-weight
relation cache in xlogutils.c is gone, and XLogReadBuffer() now
takes a RelFileNode as argument, instead of Relation. For functions
that still need a Relation struct during WAL replay, there's a new
function called CreateFakeRelcacheEntry() that returns a fake entry
like XLogOpenRelation() used to.

Andrew Dunstan committed:

- In pgsql/src/tools/add_cvs_markers add script to find .c and .h
files that are missing CVS PostgreSQL markers and add them. Avoids
third party files or those that would cause regression failures.

- In pgsql/src/tools/add_cvs_markers, prevent CVS from mangling
script.

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Pavan Deolasee sent in a WIP patch to improve VACUUM by making LAZY
VACUUM more efficient.

Heikki Linnakangas sent in another revision of his patch to refactor
the XLogOpenRelation/XLogReadBuffer interface, in preparation for the
relation forks patch, and subsequently the FSM rewrite patch.

Greg Sabino Mullane sent in a patch to format functions for better
readability in pg_dump, placing the function body last.

Bruce Momjian sent in a revision of Euler Taveira de Oliveira's patch
which simplifies formatting.c.

Euler Taveira de Oliveira which fixes a small typo in the DTrace docs.

pgsql at Mohawksoft.com sent in a patch to fix sslconfig in 8.3.3.

Zdenek Kotala sent in a patch in preparation for his in-place upgrades
patch.

Alvaro Herrera sent in two revisions of a patch to remove inclusions
of relscan.h from unneeded places.


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

pgsql-announce-unsubscribe@postgresql.org

Re: [pgsql-www] Roadmap web page

On Wed, 11 Jun 2008, Bruce Momjian wrote:

> Greg Smith wrote:
>> So basically what you want here is for CommitFest:July to become
>> CommitFest:2008-07? That's pretty reasonable and some ideas in this area
>> were already tossed around.
>
> Yes.

Done. All the existing pages were renamed, which automatically made
redirects from the old URLs if anybody had direct ones floating around.

I also did some manual fixes to more prominent pages like

http://wiki.postgresql.org/wiki/Development_information , as well as
moving archived info out of there and switching to using the redirect.
There shouldn't be a need to edit that entry page at each CommitFest
anymore.

The main place that shows an immediate improvement from the month renaming
is http://wiki.postgresql.org/wiki/Category:CommitFest which will now stay
sorted usefully moving forward.

I think that does it for changes/info you wanted to support updating the
roadmap page.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

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

Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses

On Fri, 2008-06-13 at 22:38 -0400, Andrew Sullivan wrote:

> If you don't look up
> at _least_ at connection time, this feature should be rejected on the
> grounds that it opens a new authentication hole a mile wide.

That seems conclusive to me.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and 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: [pgsql-es-ayuda] Instalacion 8.3 y 8.2 en Windows XP

2008/6/8 Terry Yapt <yapt@technovell.com>:
> Log de la Instalacion de PostgreSQL. Y los mensajes del Event Log (sistema)
> que se producen cuando se intenta arrancar el servicio. Los he puesto en el
> orden en que se producen. Siempre se producen esos tres que transcribo.
>
> Saludos.
>
>

oops... se me habia pasado este... pudiste resolverlo? dice el event
log que no puede iniciar el servicio de "inicio de sesion en red" y
ese es necesario para postgres... tendrias que revisar eso

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 8: explain analyze es tu amigo

Re: [HACKERS] psql: \edit-function

At 2008-06-15 23:35:34 -0400, tgl@sss.pgh.pa.us wrote:
>
> There's been a lot of talk (but no action) about refactoring pg_dump
> into a library plus wrapper.

Yes. After having tried to do what would have amounted to just a small
part of that work, I can see why nobody has done it yet.

> I'd much rather see that tackled in a holistic fashion.

I'd much rather see someone *else* tackle it in a holistic fashion ;),
but since I don't like the other alternatives (pg_dump --function and
pg_get_functiondef), I suppose I'd better get to work.

> PS: two trivial stylistic gripes:

Thanks, noted.

-- ams

--
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] pltcl broken on tcl8.5 ?

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Buildfarm bobcat is broken running the pltcl regression tests - see
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcat&dt=2008-06-15%2022:43:01
>> and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1.
>>
>
> I missed 8.5.1, but I can say that pltcl passes its regression test
> with both 8.5.0 and 8.5.2 on HPUX. However, that's with a
> non-thread-enabled tcl, which might be relevant.
>
> I've had problems in the past with pltcl on multilib Fedora ... are
> you by any chance using x86_64, and if so do you have tcldevel.i386
> installed as well? I've found that we tend to pick the "wrong" tcl
> if given a choice. Although I think the symptom there tends to be
> build failure not just a couple of weird test discrepancies.
>
>
>

No. I have a pure i386 environment (in a VM).

I'll dig a bit more tomorrow.

cheers

andrew

--
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] How to Sponsor a Feature

On Mon, 16 Jun 2008, Peter Eisentraut wrote:

> David Fetter wrote:
>> I forgot to post the fact that I'd put up a
>> <http://wiki.postgresql.org/wiki/How_to_sponsor_a_feature>, per my
>> TODO from the developers' meeting in Ottawa.
>
> This describes how to *develop* a feature, not how to *sponsor* it. I don't
> think this addresses the issues brought up at the meeting.

Peter is right.

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

--
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] psql: \edit-function

Abhijit Menon-Sen <ams@oryx.com> writes:
> The problem is, of course, generating the "CREATE OR REPLACE" statement.
> There is some code to do this in pg_dump.c:dumpFunc(), but it's strongly
> tied to pg_dump (global variables, output to Archive *, dependencies on
> other functions, etc.).

> I could either try to duplicate this code (and there's a lot of it), or
> rip dumpFunc() and its dependencies out of pg_dump into dumpfunc.c and
> make it callable both by pg_dump and psql. I've done some work towards
> the latter, so I know it's possible, but it's a lot of work, which I
> don't want to do if it won't be accepted anyway.

There's been a lot of talk (but no action) about refactoring pg_dump
into a library plus wrapper. ISTM you are proposing to do that for one
single bit of functionality that you've chosen at random, which somehow
doesn't seem like a good way to go at things. I'd much rather see that
tackled in a holistic fashion.

An alternative that would be worth considering is to implement a
--function switch for pg_dump (in itself a much-requested feature)
and then have psql execute "pg_dump --function whatever" as a subprocess
to obtain the initial function definition. But I'm not sure how to pass
down the database connection parameters (in particular I see no safe way
to pass down a password). Efficiency might be a problem too, since
pg_dump generally sucks out the entire database schema before worrying
about how much of it is actually needed.

Another line of thought is to implement a pg_get_functiondef() function
on the backend side and use that. I think this wouldn't help much for
pg_dump, since it has to be able to work against old backends, so you'd
still be looking at duplicating code for the foreseeable future :-(
But it would make the functionality easily available to other clients,
and there's something to be said for that.

regards, tom lane

PS: two trivial stylistic gripes:

> -static bool do_edit(const char *filename_arg, PQExpBuffer query_buf);
> +static bool do_edit(const char *, PQExpBuffer, bool *);

Do not remove parameter names from function prototypes. Whoever taught
you that that is good style was frightfully mistaken. (What happens
when you have multiple parameters of the same type? Without names, the
prototype becomes useless to readers.)

> - status = do_edit(fname, query_buf) ? PSQL_CMD_NEWEDIT : PSQL_CMD_ERROR;
> + if (do_edit(fname, query_buf, 0))

"0" is not the preferred spelling of bool "false".

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

Re: [pgus-board] [Fwd: Re: [pgus-general] PgUS bylaws]

On Sun, Jun 15, 2008 at 12:14 AM, Selena Deckelmann
<selenamarie@gmail.com> wrote:
> Sorry, this message was stalled out for a while for some reason...

Yeah, it was odd; I just got that message yesterday (although I'd
seen a reference to it later [I guess the followup?]).

---Michael Brewer
mbrewer@gmail.com

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

[COMMITTERS] pgsql: Rewrite docs section about routine vacuuming --- it's gotten

Log Message:
-----------
Rewrite docs section about routine vacuuming --- it's gotten rather mangled of
late, with lots of redundancy, bad grammar, and just plain poor exposition.
Make it clear that autovacuum is now considered the normal solution.

Modified Files:
--------------
pgsql/doc/src/sgml:
maintenance.sgml (r1.85 -> r1.86)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/maintenance.sgml?r1=1.85&r2=1.86)

--
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] How to Sponsor a Feature

Andrew Dunstan wrote:

>
> Plus an ability to filter the list on those criteria. I'd also like to
> see a space for companies to state which PostgreSQL major contributors
> are working for them. That should be of some assistance to sponsors in
> picking a development company to deal with.

+1

Joshua D. Drake

--
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] How to Sponsor a Feature

Peter Eisentraut wrote:
> Joshua D. Drake wrote:
>> In reality though, what should happen is we should have a list of
>> companies and consultants that are willing to be paid to implement
>> features, todos and bug fixes.
>
> I think the professional support company listing is already that list.

Unfortunately not, there are very few companies that have shown an
ability to work with the community for such a thing.

Sincerely,

Joshua D. Drake


--
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-advocacy] Booth Swag

Chander Ganesan wrote:
> Joshua D. Drake wrote:
>>
>>> How about some cool elephant ties too?
>>>
>>
>> Who wears ties?
>>
> Those corporate decision makers on wall street :-)

Oh... uptight people that usually die before 50 or are so angry with the
world by 60 that nobody wants to deal with them?

>
> and me...

Oops... :P

Joshua D. Drake

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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Alvaro Herrera wrote:
> Marc G. Fournier wrote:
>> I'm working on Freshmeat, sorry for delay...
>
> Can you please give access to it to someone else, so that they can help
> you in keeping it updated?
>

O.k. this is getting ridiculous, the freshmeat entry is still not
updated. Whoever has access, please get in touch with others on the web
team to make sure we are actually being responsible about the entry.

Joshua D. Drake


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

Re: [HACKERS] pg_stat_statements

I understand there must be "some" overhead because we're collecting
extra info. I'm curious if there're considerable amount of overhead
to the users who don't want such additional trance.

2008/6/16 ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>:
>
> Robert Treat <xzilla@users.sourceforge.net> wrote:
>
>> On Friday 13 June 2008 12:58:22 Josh Berkus wrote:
>> > I can see how this would be useful, but I can also see that it could be a
>> > huge performance burden when activated. So it couldn't be part of the
>> > standard statistics collection.
>>
>> A lower overhead way to get at this type of information is to quantize dtrace
>> results over a specific period of time. Much nicer than doing the whole
>> logging/analyze piece.
>
> DTrace is disabled in most installation as default, and cannot be used in
> some platforms (especially I want to use the feature in Linux). I think
> DTrace is known as a tool for developers, but not for DBAs. However,
> statement logging is required by DBAs who used to use STATSPACK in Oracle.
>
>
> I will try to measure overheads of logging in some implementation:
> 1. Log statements and dump them into server logs.
> 2. Log statements and filter them before to be written.
> 3. Store statements in shared memory.
>
> I know 1 is slow, but I don't know what part of it is really slow;
> If the reason is to write statements into disks, 2 would be a solution.
> 3 will be needed if sending statements to loggger itself is the reason
> of the overhead.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
------
Koichi Suzuki

--
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] pltcl broken on tcl8.5 ?

Andrew Dunstan <andrew@dunslane.net> writes:
> Buildfarm bobcat is broken running the pltcl regression tests - see
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcat&dt=2008-06-15%2022:43:01
> and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1.

I missed 8.5.1, but I can say that pltcl passes its regression test
with both 8.5.0 and 8.5.2 on HPUX. However, that's with a
non-thread-enabled tcl, which might be relevant.

I've had problems in the past with pltcl on multilib Fedora ... are
you by any chance using x86_64, and if so do you have tcldevel.i386
installed as well? I've found that we tend to pick the "wrong" tcl
if given a choice. Although I think the symptom there tends to be
build failure not just a couple of weird test discrepancies.

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] How to Sponsor a Feature

On Mon, Jun 16, 2008 at 12:24:28AM +0200, Peter Eisentraut wrote:
> David Fetter wrote:
> > I forgot to post the fact that I'd put up a
> > <http://wiki.postgresql.org/wiki/How_to_sponsor_a_feature>, per my
> > TODO from the developers' meeting in Ottawa.
>
> This describes how to *develop* a feature, not how to *sponsor* it.
> I don't think this addresses the issues brought up at the meeting.

It's a wiki. Please feel free to fix any errors I've made :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
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] pg_stat_statements

Robert Treat <xzilla@users.sourceforge.net> wrote:

> On Friday 13 June 2008 12:58:22 Josh Berkus wrote:
> > I can see how this would be useful, but I can also see that it could be a
> > huge performance burden when activated. So it couldn't be part of the
> > standard statistics collection.
>
> A lower overhead way to get at this type of information is to quantize dtrace
> results over a specific period of time. Much nicer than doing the whole
> logging/analyze piece.

DTrace is disabled in most installation as default, and cannot be used in
some platforms (especially I want to use the feature in Linux). I think
DTrace is known as a tool for developers, but not for DBAs. However,
statement logging is required by DBAs who used to use STATSPACK in Oracle.


I will try to measure overheads of logging in some implementation:
1. Log statements and dump them into server logs.
2. Log statements and filter them before to be written.
3. Store statements in shared memory.

I know 1 is slow, but I don't know what part of it is really slow;
If the reason is to write statements into disks, 2 would be a solution.
3 will be needed if sending statements to loggger itself is the reason
of the overhead.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

--
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-advocacy] Problem with press release

Greg,

> Is there some reason our English press releases need any non-ascii
> characters?

I'm disputing Bruce's report that there *are* any.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

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

Re: [HACKERS] pg_stat_statements

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> > Postgres 8.4 has pg_stat_user_functions view to track number of calls
> > of stored functions and time spent in them. Then, I'm thinking a
> > "sql statement" version of similar view -- pg_stat_statements.
>
> We don't have any system-wide names for statements, so this seems
> pretty ill-defined and of questionable value. Showing the text of
> statements in a view also has security problems.

Thanks. I see I have to consider security problems in whatever way I can.

I'm thinking to use hash values as system-wide IDs. Users who don't have
permissions can only see those meaningless values. SQL strings will be
hidden just same as pg_stat_activity.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

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

[HACKERS] psql: \edit-function

diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index f66fd7e..3724533 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -35,6 +35,7 @@
#include "libpq-fe.h"
#include "pqexpbuffer.h"
#include "dumputils.h"
+#include "dumpfunc.h"

#include "common.h"
#include "copy.h"
@@ -53,7 +54,7 @@
static backslashResult exec_command(const char *cmd,
PsqlScanState scan_state,
PQExpBuffer query_buf);
-static bool do_edit(const char *filename_arg, PQExpBuffer query_buf);
+static bool do_edit(const char *, PQExpBuffer, bool *);
static bool do_connect(char *dbname, char *user, char *host, char *port);
static bool do_shell(const char *command);

@@ -432,11 +433,71 @@ exec_command(const char *cmd,
expand_tilde(&fname);
if (fname)
canonicalize_path(fname);
- status = do_edit(fname, query_buf) ? PSQL_CMD_NEWEDIT : PSQL_CMD_ERROR;
+ if (do_edit(fname, query_buf, 0))
+ status = PSQL_CMD_NEWEDIT;
+ else
+ status = PSQL_CMD_ERROR;
free(fname);
}
}

+ /*
+ * \ef -- edit the named function in $EDITOR.
+ */
+
+ else if (strcmp(cmd, "ef") == 0)
+ {
+ Oid foid;
+ char *func;
+
+ func = psql_scan_slash_option(scan_state, OT_WHOLE_LINE, NULL, true);
+ if (!func)
+ {
+ psql_error("no function name specified\n");
+ status = PSQL_CMD_ERROR;
+ }
+
+ if (!lookup_function_oid(pset.db, func, &foid))
+ {
+ psql_error(PQerrorMessage(pset.db));
+ status = PSQL_CMD_ERROR;
+ }
+ else
+ {
+ bool edited = false;
+
+ termPQExpBuffer(query_buf);
+ if (foid)
+ {
+ char *s = create_or_replace_function_text(foid);
+ appendPQExpBufferStr(query_buf, s);
+ free(s);
+ }
+ else
+ {
+ printfPQExpBuffer(query_buf,
+ "CREATE FUNCTION %s%s RETURNS ... AS $$\n"
+ "...\n"
+ "$$ LANGUAGE '...'\n",
+ func, strchr(func,'(') ? "" : "(...)" );
+ }
+
+ if (!do_edit(0, query_buf, &edited))
+ {
+ status = PSQL_CMD_ERROR;
+ }
+ else if (!edited)
+ {
+ printf("No changes\n");
+ }
+ else
+ {
+ status = PSQL_CMD_SEND;
+ }
+ free(func);
+ }
+ }
+
/* \echo and \qecho */
else if (strcmp(cmd, "echo") == 0 || strcmp(cmd, "qecho") == 0)
{
@@ -1298,7 +1359,7 @@ editFile(const char *fname)

/* call this one */
static bool
-do_edit(const char *filename_arg, PQExpBuffer query_buf)
+do_edit(const char *filename_arg, PQExpBuffer query_buf, bool *edited)
{
char fnametmp[MAXPGPATH];
FILE *stream = NULL;
@@ -1420,6 +1481,10 @@ do_edit(const char *filename_arg, PQExpBuffer query_buf)
psql_error("%s: %s\n", fname, strerror(errno));
error = true;
}
+ else if (edited)
+ {
+ *edited = true;
+ }

fclose(stream);
}
Hi.

I'm working on a patch where if you say "\ef foo" in psql, it'll start
$EDITOR with a "CREATE OR REPLACE FUNCTION" statement to recreate the
function. So you edit and save and quit, and if you made any changes,
psql will execute the statement.

The psql(/command.c) parts of this are quite simple. I've attached a
patch to demonstrate the idea.

The problem is, of course, generating the "CREATE OR REPLACE" statement.
There is some code to do this in pg_dump.c:dumpFunc(), but it's strongly
tied to pg_dump (global variables, output to Archive *, dependencies on
other functions, etc.).

I could either try to duplicate this code (and there's a lot of it), or
rip dumpFunc() and its dependencies out of pg_dump into dumpfunc.c and
make it callable both by pg_dump and psql. I've done some work towards
the latter, so I know it's possible, but it's a lot of work, which I
don't want to do if it won't be accepted anyway.

I would appreciate some advice on how to proceed.

-- ams

[SQL] Results with leading zero

I have a table

CREATE TABLE problem (
problem_id integer,
solution_count integer
);

INSERT INTO problem VALUES (1001, 4);
INSERT INTO problem VALUES (1012, 11);

SELECT * from problem;

problem_id | solution_count
------------+---------------
1001 | 4
1012 | 11
(2 rows)


Is there a way I could write a query to produce the following? I will
need the leading zero for solution < 10

problem_id | solution
-------------+------------
1001 | 01
1001 | 02
1001 | 02
1001 | 04
1012 | 01
1012 | 02
1012 | 03
1012 | 04
1012 | 05
1012 | 06
1012 | 07
1012 | 08
1012 | 09
1012 | 10
1012 | 11
(15 rows)

Thanks.

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

Re: [HACKERS] planner document?

On Mon, 2008-06-16 at 08:59 +0800, laser wrote:
> Hi,
>
> we recently try to build a costumer index type around 8.3, for now
> want to teach
> planner to pick up specific index for our query, so we'd like to use
> some document
> about how a query tree trun into different query plan and how to
> decide which one
> to use. Is there any document about that? Any hints will be great
> appreciated!
>

In the PostgreSQL source:

src/backend/optimizer/README

Regards,
Jeff Davis


--
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-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Dave Page wrote:
> On Sat, Jun 14, 2008 at 5:16 PM, Jonathan Fuerth <fuerth@sqlpower.ca> wrote:
>> Thanks for the clarification, Dave! I will poll the RSS feed instead
>> of the FTP directory listing. I'm going to assume every title in the
>> feed is a release number. This is true now; is it a safe assumption in
>> the medium-to-long run?
>
> Yeah, I think so. The purpose of that feed really is just for the
> version numbers.

Yes, that is the idea. The only real reason there is a text on the items
at all is that it's required for the feed to validate :-) It's there for
automatic scrpits to be able to rely on, so we're not going to change
the format of the title unless there's a *very* compelling reason.

//magnus


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

Re: [pgsql-es-ayuda] Rendimiento sin COMMIT

On Sun, Jun 15, 2008 at 12:46 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Jaime Casanova escribió:
>> On Fri, Jun 13, 2008 at 10:28 AM, Alvaro Herrera
>> <alvherre@commandprompt.com> wrote:
>
>> > No puedes usar cursores directamente.
>> >
>> ?? porque?? me estoy perdiendo algo??
>
> Hmm, ¿cambiaron esto hace poco? Que yo recuerde, no se podía.
>

Desde el 8.3 se puede hacer WHERE CURRENT OF de un cursor en plpgsql,
o te referias a otra cosa?
http://www.postgresql.org/docs/8.3/static/plpgsql-cursors.html#PLPGSQL-CURSOR-USING

CREATE OR REPLACE FUNCTION prueba_1(dw01 integer) RETURNS smallint AS
$BODY$
DECLARE
jcb cursor for select *
from test1
where col1 = dw01
for update;
dw21 record;
BEGIN
OPEN jcb;
LOOP
FETCH jcb INTO dw21;
EXIT WHEN NOT FOUND;
update test1 set col2 = 0
where CURRENT OF jcb;
END LOOP;
CLOSE jcb;
RETURN 1;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [pgsql-es-ayuda] Rendimiento sin COMMIT

Jaime Casanova escribió:
> On Fri, Jun 13, 2008 at 10:28 AM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:

> > No puedes usar cursores directamente.
> >
>
> ?? porque?? me estoy perdiendo algo??

Hmm, ¿cambiaron esto hace poco? Que yo recuerde, no se podía.

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Privilegios

Jaime Casanova escribió:
> 2008/6/14 Rommel Romero <rach.patrick@gmail.com>:
> >
> > Bien...luego les cambie de propietario a mi base y mis tablas, ahora son de
> > propiedad de [migrupo], luego les di privilegios en todas las tablas de la
> > siguiente manera.
> >
> > GRANT ALL PRIVILEGES ON TABLE [mis tablas] TO GROUP [migrupo] ;
> >
>
> asignaste a los usuarios al grupo, verdad?
>
> GRANT [tugrupo] TO [tutabla];

Lo otro es que hay que hacer que el rol tenga la propiedad INHERIT; o
bien, que los usuarios hagan "SET ROLE tugrupo" antes de intentar
acceder a las tablas.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses

On Fri, 13 Jun 2008 16:14:13 -0400 Alvaro Herrera wrote:

> Andrew Sullivan wrote:
>
> > This is because DNS RRs have a TTL on them, so looking up the host at
> > any moment other than when you're actually doing the authentication is
> > prone to error.
>
> Perhaps the solution to this problem is to do the lookups and store the
> TTL of each answer. At the time of actually checking you need only get
> a new answer for those that expired.

That's too much overhead in the postmaster.
A better way would be some documentation how one can improve the DNS
performance, like using an external DNS cache ect.

I would also like to see a note that the DNS lookup could seriously
slow down the authentication process.


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

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

[ADMIN] Advice on running two database clusters on one server machine

Hi all,

We are implementing a hospital information system and a human
resources/payroll processing system on two identical dedicated servers with
two Xeon Quad Core processors and 32 GB RAM each, both servers being attached
via FC to a SAN, and both applications running on PostgreSQL 8.3 / CentOS 51.

We are wondering about the advisability to distribute the databases between
the two server machines, both machines acting as active production systems
for one application each, and as warm standby servers for the other, using
WAL shipping to a second database cluster running on another port on each of
the two server machines.

What would be the performance cost of doing so, rather than running all
databases on one database cluster on one machine, and using the second
machine as a warm standby server for all databases of the two applications?

What other considerations should we take into account? We have no prior
experience with PostgeSQL administration, having run our previous systems on
Windows Servers and MS SQL Server.

Thanks to all for your input!
--
Andreas Philipp
Clínica Universitaria Teletón
Chía, Colombia

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

[ADMIN] Advice on running two database clusters on one server machine

Hi all,

We are implementing a hospital information system and a human
resources/payroll processing system on two identical dedicated servers with
two Xeon Quad Core processors and 32 GB RAM each, both servers being attached
via FC to a SAN, and both applications running on PostgreSQL 8.3 / CentOS 51.

We are wondering about the advisability to distribute the databases between
the two server machines, both machines acting as active production systems
for one application each, and as warm standby servers for the other, using
WAL shipping to a second database cluster running on another port on each of
the two server machines.

What would be the performance cost of doing so, rather than running all
databases on one database cluster on one machine, and using the second
machine as a warm standby server for all databases of the two applications?

What other considerations should we take into account? We have no prior
experience with PostgeSQL administration, having run our previous systems on
Windows Servers and MS SQL Server.

Thanks to all for your input!

Andreas Philipp
Clínica Universitaria Teletón
Chía, Colombia

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

[ADMIN] Advice on running two database clusters on one server machine

Hi all,

We are implementing a hospital information system and a human
resources/payroll processing system on two identical dedicated servers with
two Xeon Quad Core processors and 32 GB RAM each, both servers being attached
via FC to a SAN, and both applications running on PostgreSQL 8.3 / CentOS 51.

We are wondering about the advisability to distribute the databases between
the two server machines, both machines acting as active production systems
for one application each, and as warm standby servers for the other, using
WAL shipping to a second database cluster running on another port on each of
the two server machines.

What would be the performance cost of doing so, rather than running all
databases on one database cluster on one machine, and using the second
machine as a warm standby server for all databases of the two applications?

What other considerations should we take into account? We have no prior
experience with PostgeSQL administration, having run our previous systems on
Windows Servers and MS SQL Server.

Thanks to all for your input!

Andreas Philipp
Clínica Universitaria Teletón
Chía, Colombia

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

Re: [GENERAL] XML output & multiple SELECT queries

Peter Billen wrote:
> I would like to ask a question about outputting data as XML. Say I have two
> tables:
>
> team(integer id, text name);
> player_of_team(integer id, integer team_id, text name); (team_id is FK to
> team.id)
>
> I would like to query both tables to get following example XML output:
>
> <team name="Real Madrid">
>      <players>
>          <name>Garcia</name>
>          <name>Robinho</name>
>      </players>
> </team>

SELECT XMLElement(name team, XMLAttributes(team.name as name), XMLElement(name
players, XMLAgg(XMLElement(name name, player_of_team.name)))) FROM team JOIN
player_of_team ON team.id = player_of_team.team_id GROUP BY team.name;

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

Re: [pgsql-www] Translated documentations

Joshua D. Drake wrote:
> The docs do not appear to have any translation
> infrastructure. Peter would be a better person to answer that question.

I have no experience with any documentation translation tools or
infrastructure. I'd be glad to provide whatever resources I can to help,
such as the pgtranslation pgfoundry project, but I don't really know any more
about this than the rest of you.

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

[COMMITTERS] pgsql: Make DROP INDEX lock the parent table before locking the index.

Log Message:
-----------
Make DROP INDEX lock the parent table before locking the index. This behavior
is necessary to avoid deadlock against ordinary queries, but we'd broken it
with recent changes that made the DROP machinery lock the index before
arriving at index_drop. Per intermittent buildfarm failures.

Modified Files:
--------------
pgsql/src/backend/commands:
tablecmds.c (r1.257 -> r1.258)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c?r1=1.257&r2=1.258)

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

Re: [pgsql-advocacy] Booth Swag

On Sun, 15 Jun 2008 12:39:28 +0100 Dave Page wrote:

> On 14 Jun 2008, at 23:21, Andreas 'ads' Scherbaum <adsmail@wars-
> nicht.de> wrote:
>
> > On Tue, 10 Jun 2008 22:47:25 -0700 gabrielle wrote:
> >
> >> On Tue, Jun 10, 2008 at 8:47 PM, Michael Alan Brewer <mbrewer@gmail.com
> >> > wrote:
> >>> I'd love to see oval, Euro-style stickers with either "PG", "PgSQL",
> >>> or "psql" on them; those, plus temporary tattoos of our elephant
> >>> logo
> >>> should work.
> >>
> >> Ooh, I like that sticker idea. We had elephant logo stickers at
> >> LFNW.
> >
> > Like the stickers we had at FOSDEM earlier this year?
> > I have two sheets, one with white and one with silver background, both
> > have an elephant on them.
> >
> > Nobody wanted this stickers ...
> >
> We had stickers? I didn't know that, and I was on the booth for the
> better part of two days!

Oh, of course, we had:

http://andreas.scherbaum.la/pictures/v/events/fosdem_2008/dsc_3485_640x480.jpg.html
http://andreas.scherbaum.la/pictures/v/events/fosdem_2008/dsc_3486_640x480.jpg.html
http://andreas.scherbaum.la/pictures/v/events/fosdem_2008/dsc_3487_640x480.jpg.html
http://andreas.scherbaum.la/pictures/v/events/fosdem_2008/dsc_3494_640x480.jpg.html
http://andreas.scherbaum.la/pictures/v/events/fosdem_2008/dsc_3495_640x480.jpg.html
http://andreas.scherbaum.la/pictures/v/events/fosdem_2008/dsc_3497_640x480.jpg.html

Next to the big 60 cm (yes, that's an ISO unit ;-) ) elephant.


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

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

Re: [PERFORM] how to find the sql using most of the i/o in an oltp system

Check out pgFouine.

Sent from my iPhone

On Jun 15, 2008, at 10:41 AM, "Uwe Bartels" <uwe.bartels@gmail.com> wrote:

Hi Alexander,

thanks for you answer.
What you wrote in terms of postgres I knew. I just tested to log all statements with statistics. This is a lot of unstructured data in a logfile. But this is the best I found as far.

The database is running on a solaris box. So DTrace is no problem. I couldn't find any dtrace scripts for postgres. Do you know any scripts except this sample script?

Thanks.
Uwe

On Sun, Jun 15, 2008 at 4:03 PM, Alexander Staubo <alex@bengler.no> wrote:
On Sun, Jun 15, 2008 at 3:48 PM, Uwe Bartels <uwe.bartels@gmail.com> wrote:
> Tuning a sql statements I'm familiar with. Finding a sql statement which
> takes too long due to i/o is probably easy as well. But how about statements
> that take about 100 ms, that read a lot and that are executed several times
> per second?

Take a look at the PostgreSQL manual chapter on monitoring and statistics:

 http://www.postgresql.org/docs/8.3/interactive/monitoring.html

If you have access to DTrace (available on Solaris, OS X and possibly
FreeBSD), you could hook the low-level system calls to reads and
writes. If you don't have access to DTrace, the pg_statio_* set of
tables is your main option. In particular, pg_statio_user_tables and
pg_statio_user_indexes. See the documentation for the meaning of the
individual columns.

Unfortunately, the statistics tables are not transaction-specific
(indeed I believe they only update once you commit the transaction,
and then only after a delay), meaning they capture statistics about
everything currently going on in the database. The only way to capture
statistics about a single query, then, is to run it in complete
isolation.

Alexander.

Re: [PERFORM] how to find the sql using most of the i/o in an oltp system

Hi Alexander,

thanks for you answer.
What you wrote in terms of postgres I knew. I just tested to log all statements with statistics. This is a lot of unstructured data in a logfile. But this is the best I found as far.

The database is running on a solaris box. So DTrace is no problem. I couldn't find any dtrace scripts for postgres. Do you know any scripts except this sample script?

Thanks.
Uwe

On Sun, Jun 15, 2008 at 4:03 PM, Alexander Staubo <alex@bengler.no> wrote:
On Sun, Jun 15, 2008 at 3:48 PM, Uwe Bartels <uwe.bartels@gmail.com> wrote:
> Tuning a sql statements I'm familiar with. Finding a sql statement which
> takes too long due to i/o is probably easy as well. But how about statements
> that take about 100 ms, that read a lot and that are executed several times
> per second?

Take a look at the PostgreSQL manual chapter on monitoring and statistics:

 http://www.postgresql.org/docs/8.3/interactive/monitoring.html

If you have access to DTrace (available on Solaris, OS X and possibly
FreeBSD), you could hook the low-level system calls to reads and
writes. If you don't have access to DTrace, the pg_statio_* set of
tables is your main option. In particular, pg_statio_user_tables and
pg_statio_user_indexes. See the documentation for the meaning of the
individual columns.

Unfortunately, the statistics tables are not transaction-specific
(indeed I believe they only update once you commit the transaction,
and then only after a delay), meaning they capture statistics about
everything currently going on in the database. The only way to capture
statistics about a single query, then, is to run it in complete
isolation.

Alexander.

Re: [GENERAL] Need Tool to sync databases with 8.3.1

D. Dante Lorenso wrote on 15.06.2008 01:00:
> I need a tool that will compare 2 database schemas and allow me to
> migrate changes from one database to another. What tools do the rest of
> you use to accomplish this task?

You can try my SQL Workbench/J:.
http://www.sql-workbench.net/manual/wb-commands.html#command-schema-diff

It writes out the differences as an XML file.

I have sample XSLT transformations to create SQL statements out of that XML on
my homepage as well: http://www.sql-workbench.net/xslt.html

Regards
Thomas


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

[PERFORM] how to find the sql using most of the i/o in an oltp system

Hi,

I read a lot about postgres tuning and did some of it. But one of the
things, when you start tuning a system that is completely new to you, is
checking which sql statement(s) cost most of the resources.

cpu instensive sql seems easy to find.
But how do I find i/o intensive sql as fast as possible?

Tuning a sql statements I'm familiar with. Finding a sql statement which
takes too long due to i/o is probably easy as well. But how about
statements that take about 100 ms, that read a lot and that are executed
several times per second?

To ask the same question just different - Is there a possibility to
check how many pages/kB a sql reads from shared buffer and how many
pages/kB from disk?
Is there a possibility to read or create historical records about how
often, how fast one sql is run and how many reads it used from shared
buffers, from disk an so on.


Best regards,
Uwe

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

Re: [ADMIN] Storing images and other data in PostgreSQL from Ms Access

No need to do it. On the web I found a article which states to use the data type 'lo' rather than 'bytea' and after refreshing the link works well. No problem faced. tested with MS access 2003 and 2007. Thanks to community.
CPK

On Sun, Jun 15, 2008 at 9:08 AM, JGuillaume (ioguix) de Rorthais <ioguix@free.fr> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

*IIRC*, using bytea type works like a charm for OLE stuff from MS
Access...

Try to link your tables with the ANSI driver, then change the ODBC
source to the UNICODE one. I don't know why, but ISTM that MSAccess
perform a better type mapping with the ANSI driver...at least, TEXT ->
Memo, so I probably linked bytea -> OLE using the ANSI driver when I
tried ?

- --
Guillaume (ioguix) de Rorthais

C K a écrit :
> Hi All,
> I am testing the postgresql as a back-end for a project having ms
> access as a front-end. I have linked postgresql tables and started
> using. It works well for all data except the binary data. When used
> to insert/retrieve data from such fields, ms access gives error that
> it can't recognize the data.
> What to do? As per my knowledge postgresql adds some bytes to the
> binary data to be uploaded. I have eralier used mysql and it work
> well. Is there any solution for this?
>
> Please help.
> I am using Postgresql 8.3.1 and unicode driver with MS Access 2003
> and most current patches from microsoft applied on Windows Xp.
>
> Thanks
> CPK
>
> --
> Keep your Environment clean and green.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIVI7KxWGfaAgowiIRAhwLAJoCIPP6kWoZGsvdNJvkKx38xIUtaQCeKYrk
ah6gAsw1uMVhqFENBhgR9jk=
=agg/
-----END PGP SIGNATURE-----




--
Keep your Environment clean and green.

Re: [pdxpug] Does anyone have a 5th generation iPod? or 3rd generation ipod, or ipod classic?

>>>>> "Selena" == Selena Deckelmann <selenamarie@gmail.com> writes:

Selena> We would like the ipod to record our meeting :) Can you bring it?

If I wasn't going to be in Reno, sure. Although, my Zoom H2 is a far better
recorder, and I always have it with me. So, if you see my face, you're more
than welcome to ask me to record anything you want. If you see my face
thursday, you're probably hallucinating. :)

Which recorder do you have? I prefer the MicroMemo to the Belkin, because the
mike-on-a-boom gets it away from the iPod's drive motor, unlike the Belkin,
where in a quiet part of the talk I often hear the iPod drive.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

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

Re: [pdxpug] Does anyone have a 5th generation iPod? or 3rd generation ipod, or ipod classic?

On Sun, Jun 15, 2008 at 4:45 AM, Randal L. Schwartz
<merlyn@stonehenge.com> wrote:
>>>>>> "Selena" == Selena Deckelmann <selenamarie@gmail.com> writes:
>
> Selena> We got a podcast recording device, but it doesn't work with our ipod :(
>
> I have a 5th generation ipod and *two* recorders for it, and I use them both.
> Not sure whether you're asking if someone wants another recorder, or you want
> their ipod.

We would like the ipod to record our meeting :) Can you bring it?

-selena


--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

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

Re: [pdxpug] Does anyone have a 5th generation iPod? or 3rd generation ipod, or ipod classic?

>>>>> "Selena" == Selena Deckelmann <selenamarie@gmail.com> writes:

Selena> We got a podcast recording device, but it doesn't work with our ipod :(

I have a 5th generation ipod and *two* recorders for it, and I use them both.
Not sure whether you're asking if someone wants another recorder, or you want
their ipod.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

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

Re: [pgsql-advocacy] Booth Swag

Sent from my iPhone

On 14 Jun 2008, at 23:21, Andreas 'ads' Scherbaum <adsmail@wars-
nicht.de> wrote:

> On Tue, 10 Jun 2008 22:47:25 -0700 gabrielle wrote:
>
>> On Tue, Jun 10, 2008 at 8:47 PM, Michael Alan Brewer <mbrewer@gmail.com
>> > wrote:
>>> I'd love to see oval, Euro-style stickers with either "PG", "PgSQL",
>>> or "psql" on them; those, plus temporary tattoos of our elephant
>>> logo
>>> should work.
>>
>> Ooh, I like that sticker idea. We had elephant logo stickers at
>> LFNW.
>
> Like the stickers we had at FOSDEM earlier this year?
> I have two sheets, one with white and one with silver background, both
> have an elephant on them.
>
> Nobody wanted this stickers ...
>
We had stickers? I didn't know that, and I was on the booth for the
better part of two days!

/d

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

Re: [GENERAL] why sequential scan is used on indexed column ???

Hello, Tom.

> So I think the OP's
> problem is purely a statistical one, or maybe he's in a situation where
> he should reduce random_page_cost.)
>
What could be done solving that "statistical problem"? :) Current value
for random_page_cost is 4. What value would you suggest?

Julius Tuskenis

--
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] why sequential scan is used on indexed column ???

Hi Michael.

Thank you for your answer. I've checked - enable_nestloop is true. I did
ANALYZE, but that didn't help. The sequential scan is still used.... Any
more ideas why?

Julius Tuskenis

Michael Fuhr rašė:
> On Sat, Jun 14, 2008 at 04:59:44PM +0200, Andreas Kretschmer wrote:
>
>> Julius Tuskenis <julius.tuskenis@gmail.com> schrieb:
>>
>>> I have a question concerning performance. One of my queries take a long
>>> to execute. I tried to do "explain analyse" and I see that the
>>> sequential scan is being used, although I have indexes set on columns
>>> that are used in joins. The question is - WHY, and how to change that
>>> behavior???
>>>
>> Try to create an index on apsilankymai.sas_id
>>
>
> In the DDL that Julius posted apsilankymai doesn't have an sas_id
> column.
>
> The join is on apsilankymai.aps_saskaita = b_saskaita.sas_id. Both
> columns have an index: b_saskaita.sas_id is a primary key so it
> should have an index implicitly, and apsilankymai.aps_saskaita has
> an explicit CREATE INDEX statement. The WHERE clause is on
> b_saskaita.sas_subjektas, which also has an explicit CREATE INDEX
> statement. Unless I'm mistaken all relevant columns have an index.
>
> A few of the row count estimates differ from reality:
>
>
>> Hash Join (cost=5.17..10185.89 rows=6047 width=138) (actual time=10698.539..10698.539 rows=0 loops=1)
>>
>
>
>> Bitmap Heap Scan on b_saskaita (cost=2.03..5.14 rows=9 width=96) (actual time=31.473..31.489 rows=1 loops=1)
>>
>
> However, that might not be entirely responsible for the questionable
> plan. I created a test case that has close to the same estimated and
> actual row counts and has the same plan if I disable enable_nestloop:
>
> set enable_nestloop to off;
>
> explain analyze
> select *
> FROM b_saskaita JOIN apsilankymai ON (aps_saskaita = sas_id)
> where sas_subjektas = 20190;
>
> QUERY PLAN
> --------------------------------------------------------------------------------------------------------------------------------------
> Hash Join (cost=6.54..5814.42 rows=5406 width=286) (actual time=3222.429..3222.429 rows=0 loops=1)
> Hash Cond: (apsilankymai.aps_saskaita = b_saskaita.sas_id)
> -> Seq Scan on apsilankymai (cost=0.00..4627.50 rows=300350 width=42) (actual time=0.085..1514.863 rows=300350 loops=1)
> -> Hash (cost=6.43..6.43 rows=9 width=244) (actual time=0.122..0.122 rows=1 loops=1)
> -> Bitmap Heap Scan on b_saskaita (cost=2.32..6.43 rows=9 width=244) (actual time=0.089..0.095 rows=1 loops=1)
> Recheck Cond: (sas_subjektas = 20190)
> -> Bitmap Index Scan on fki_sas_subjektas (cost=0.00..2.32 rows=9 width=0) (actual time=0.066..0.066 rows=1 loops=1)
> Index Cond: (sas_subjektas = 20190)
> Total runtime: 3222.786 ms
>
> I get a better plan if I enable nested loops:
>
> set enable_nestloop to on;
>
> explain analyze
> select *
> FROM b_saskaita JOIN apsilankymai ON (aps_saskaita = sas_id)
> where sas_subjektas = 20190;
>
> QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------------
> Nested Loop (cost=79.93..4660.23 rows=5406 width=286) (actual time=1.000..1.000 rows=0 loops=1)
> -> Seq Scan on b_saskaita (cost=0.00..10.25 rows=9 width=244) (actual time=0.116..0.870 rows=1 loops=1)
> Filter: (sas_subjektas = 20190)
> -> Bitmap Heap Scan on apsilankymai (cost=79.93..441.58 rows=6007 width=42) (actual time=0.084..0.084 rows=0 loops=1)
> Recheck Cond: (apsilankymai.aps_saskaita = b_saskaita.sas_id)
> -> Bitmap Index Scan on idx_aps_saskaita (cost=0.00..78.43 rows=6007 width=0) (actual time=0.068..0.068 rows=0 loops=1)
> Index Cond: (apsilankymai.aps_saskaita = b_saskaita.sas_id)
> Total runtime: 1.321 ms
>
> Julius, do you perchance have enable_nestloop = off? If so, do you
> get a better plan if you enable it? Also, have you run ANALYZE
> lately?
>
>

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

Re: [pgsql-advocacy] Booth Swag

Hello,

On Tue, 10 Jun 2008 15:14:49 -0700 Josh Berkus wrote:

> Donation Swag
> (stuff to use to solicit donations)
> T-shirts
> Enamel Pins
> Stickers??
> Blue Elephants?? (need to find cheaper source)
> USB sticks??

You wanted to send me a contact address. If they PHP guys produce the
toys somewhere in europe, i can handle that.


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

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

Re: [pgsql-advocacy] Booth Swag

On Sat, 14 Jun 2008 21:05:00 -0700 Selena Deckelmann wrote:

> On Sat, Jun 14, 2008 at 3:21 PM, Andreas 'ads' Scherbaum
> <adsmail@wars-nicht.de> wrote:
> > On Tue, 10 Jun 2008 22:47:25 -0700 gabrielle wrote:
> >
> >> On Tue, Jun 10, 2008 at 8:47 PM, Michael Alan Brewer <mbrewer@gmail.com> wrote:
> >> > I'd love to see oval, Euro-style stickers with either "PG", "PgSQL",
> >> > or "psql" on them; those, plus temporary tattoos of our elephant logo
> >> > should work.
> >>
> >> Ooh, I like that sticker idea. We had elephant logo stickers at LFNW.
> >
> > Like the stickers we had at FOSDEM earlier this year?
> > I have two sheets, one with white and one with silver background, both
> > have an elephant on them.
> >
> > Nobody wanted this stickers ...
>
> I never saw the FOSDEM ones! Can you send me a link or the art for them?

That's a problem. Right after i sent my mail i went into my storage
room and searched for the sheeds - could not find them. Right now i'm
not even sure if i brought them back from Brussels.
Will search again later today.

Description:
the stickers are approx 3cm, square, silver or white background and
have an elephant logo.

Looks very good - but as i said, almost nobody wanted one.

> My plan is to make ones like these, but with the elephant on them:
>
> http://skitch.com/selena/pstf/photo-50

Looks very cute!

Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

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