Saturday, May 10, 2008

Re: [HACKERS] Setting a pre-existing index as a primary key

Yes, I just think PREBUILT conveys the meaning of the command more
appropriately. I could care less though.

On Sat, May 10, 2008 at 5:35 PM, Gregory Stark <stark@enterprisedb.com> wrote:
> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
>
>> So, would anyone be averse to something like the following:
>>
>> ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame
>>
>> If the user doesn't specify CONSTRAINT constraint_name, it will
>> default to current implicit behavior of col_pkey.
>
> This is all so that the primary key shows up with a nice "PRIMARY KEY" instead
> of just the unique index?
>
> The "PREBUILT" seems unnecessary in that syntax.
>
> --
> Gregory Stark
> EnterpriseDB

http://www.enterprisedb.com
> Ask me about EnterpriseDB's Slony Replication support!
>

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | 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: [HACKERS] Setting a pre-existing index as a primary key

"Jonah H. Harris" <jonah.harris@gmail.com> writes:

> So, would anyone be averse to something like the following:
>
> ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame
>
> If the user doesn't specify CONSTRAINT constraint_name, it will
> default to current implicit behavior of col_pkey.

This is all so that the primary key shows up with a nice "PRIMARY KEY" instead
of just the unique index?

The "PREBUILT" seems unnecessary in that syntax.

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's Slony Replication 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] ecpg localization

Peter Eisentraut wrote:

> I suggest you keep working on this, and we will reconsider a more complete
> patch at a later date.
>
This is a second try. Fix some issues pointed by Peter. It's a little
fatter 'cause I worked on almost all of the strings. I attempted to
mimic the postgresql style but I think that those strings need more work
on as I pointed out in the first e-mail.
Again, It is necessary to overhaul the ecpg emit-some-message-functions.
For example, some of them have tips in it, other ones is
just-for-information message, and so on. I don't have in mind what is a
good draft for those messages. Suggestions?


--
Euler Taveira de Oliveira

http://www.timbira.com/

Re: Re: [PERFORM] Re: Query Optimization with Kruskal’s Algorithm

On Sat, May 10, 2008 at 5:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
>> Repost to -hackers, you're more likely to get a response on this topic.
>
> Probably not, unless you cite a more readily available reference.
> (I dropped my IEEE membership maybe fifteen years ago ...)

Yeah, I don't have one either. Similarly, I couldn't find anything
applicable to the PG implementation except references to the paper.
Wikipedia has the algorithm itself
(http://en.wikipedia.org/wiki/Kruskal's_algorithm), but I was more
interested in the actual applicability to PG and any issues they ran
into.

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.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: [HACKERS] Setting a pre-existing index as a primary key

So, would anyone be averse to something like the following:

ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame

If the user doesn't specify CONSTRAINT constraint_name, it will
default to current implicit behavior of col_pkey.

-Jonah


On Sat, May 10, 2008 at 1:08 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> Tom Lane wrote:
>
>> Apparently your definition of "easy" depends entirely on
>> keystrokes and not at all on memory/cognitive burden.
>
> I was trying to remove one opportunity for human error, which is tied to
> memory and cognitive burden. It is very easy to fat finger something. Is it
> a critical error? No. Is it obnoxious to have to go back and fix it, yes.
> When you are going back to fix, are you going to be grousing about how
> PostgreSQL doesn't make this easier, maybe.
>
>>
>> IMHO a utility command should do one easily-explained thing. The fewer
>> options the better.
>
> I would agree with this except that by my definition your argument fails.
> You are adding options by not allowing a sane default that applies
> consistency to the database. I believe this will cause more trouble than
> having the limitation in the first place.
>
> Anyway, I have made my arguments. I believe we are still in the middle of a
> commit fest.
>
> Sincerely,
>
> Joshua D. Drake
>
>

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | 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: Re: [PERFORM] Re: Query Optimization with Kruskal’s Algorithm

"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> Repost to -hackers, you're more likely to get a response on this topic.

Probably not, unless you cite a more readily available reference.
(I dropped my IEEE membership maybe fifteen years ago ...)

regards, tom lane

--
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] bloated heapam.h

Alvaro Herrera <alvherre@commandprompt.com> writes:
> The one that makes a bit more sense is a new syncscan.h. And there are
> a lot of things in heapam.h that actually correspond to tuple
> manipulation (heap_form_tuple and so on), so perhaps a new header file
> would be appropriate, but there's already htup.h which contains
> tuple-related stuff.

After actually looking at the header a bit ...

+1 for moving fastgetattr, heap_getattr, and the heaptuple.c functions
to htup.h. I don't see any big gain from relocating the other stuff;
it seems to largely all use about the same set of typedefs.

It looks to me actually that a large part of your complaint is that
heapam.h #includes more than it has to. Have you tried just cutting its
#include list to the minimum needed to compile its function declarations?
Likely this would force more #includes in .c files but I don't object
to that. (I might be wrong, but I believe that Bruce's script for
removing "unnecessary" #includes is not bright enough to make such
tradeoffs, so it'd let bloated #include lists in headers survive.)

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] libpqtypes - libpqtypes: removed reference to university of cali from

Log Message:
-----------
removed reference to university of cali from LICENSE file

Modified Files:
--------------
libpqtypes:
LICENSE (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/LICENSE.diff?r1=1.1&r2=1.2)

--
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-es-ayuda] Programa similar a Enterprise Manager

si pgadmin3, navicat, y varios mas que no recuerdo ahorita

2008/5/10 Davide Barzi! <developower@hotmail.com>:
Hola amigos quisiera saber si existe un Programa similar a Enterprise Manager de SQL, pero para PG y si es free mucho mejor.

Explore the seven wonders of the world Learn more!



--
atte

juan antonio jaimes valle
toluca, mexico
juanjava@gmail.com
juanjava@yahoo.com

Re: [BUGS] statement_timeout and crosstab

"Tiago D. Jacobs - iMDT" <tiago@imdt.com.br> writes:
> ( 5 ) Here's the problem (it returns without breaking by timeout):

Hm, works fine here:

ERROR: canceling statement due to statement timeout
CONTEXT: SQL statement "SELECT i.item_name::text As row_name,
to_char(if.action_date, 'mon')::text As bucket,
SUM(if.num_used)::integer As bucketvalue
FROM inventory As i INNER JOIN inventory_flow As if
ON i.item_id = if.item_id
AND action_date BETWEEN date '2007-01-01' and date '2007-12-31
23:59'
GROUP BY i.item_name, to_char(if.action_date, 'mon'),
date_part('month', if.action_date)
ORDER BY i.item_name"

How long does the query run on your machine? If it's less than 10ms,
maybe what you're seeing is just that the resolution of
statement_timeout isn't necessarily less than 10ms, depending on
platform.

What is the platform, anyway? And what Postgres version?

regards, tom lane

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

Re: [pgsql-es-ayuda] Curso

ok, mira yo soy novato pero para realizar los videos no mucho, y a ustedes los he seguido porque quiero aprender para tener conocimiento de la db postgresql, asi que si me dan conocimiento yo lo trasmito, y por otro lado que bueno tener gente como tu alvaro que me he comunicado contigo (el que se fue a argentina, por cursos de postgresql y postgis, desepcionado), prestas ayuda, no es cierto perdon das ayuda sin interes. pero no se que pasa con grupos de postgresql en español nadie quiere entrar o son muy estrechos, y conforme vaya aprendiendo lo que pueda lo realizare con videotutoriales, por el momento estoy de aprendiz con el ing. roberto andrade en mexico e iniciando con linux para pasarme directamente con el asi la db. disculpoa el choro pero me encantaria que se dieran cursos con cuotas de recuperacion y se lo estoy proponiendo al ing. andrade.

On Thu, May 8, 2008 at 9:29 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote:
juan jaimes escribió:
> perdon pero yo ayudaria a realizar los tutoriales, y estoy dispuesto aunque
> esto siga siendo una calentura ya que la pagina que se propuso el año pasado
> no se ha realizado (almenos eso pienso) ya que sigo la lista y espero que no
> se me haya pasado nada

Eres bienvenido a realizar todos los tutoriales que seas capaz.

http://wiki.postgresql.org/wiki/Espa%C3%B1ol

Nos falta contenido en español.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.



--
atte

juan antonio jaimes valle
toluca, mexico
juanjava@gmail.com
juanjava@yahoo.com

[pgsql-es-ayuda] Programa similar a Enterprise Manager

Hola amigos quisiera saber si existe un Programa similar a Enterprise Manager de SQL, pero para PG y si es free mucho mejor.

Explore the seven wonders of the world Learn more!

Re: [PERFORM] Re: Query Optimization with Kruskal’s Algorithm

Repost to -hackers, you're more likely to get a response on this topic.

On Sat, May 10, 2008 at 1:31 PM, Rauan Maemirov <rauan1987@gmail.com> wrote:
> On May 8, 2:09 am, a...@purefiction.net ("Alexander Staubo") wrote:
>> On 5/7/08, Tarcizio Bini <tarcizi...@c3sl.ufpr.br> wrote:
>>
>> > I'm working on optimizing queries using the Kruskal algorithm
>> > (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4318118).
>>
>> That paper looks very interesting. I would love to hear what the
>> PostgreSQL committers think of this algorithm.
>>
>> Alexander.
>>
>> --
>> Sent via pgsql-performance mailing list (pgsql-performa...@postgresql.org)
>> To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-performance
>
> I also would like to hear from them. But seems like the thread is
> loosed in tonn of other threads.
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/

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

[pgsql-advocacy] We're in the LWE-SF mailer!

All:

Thanks to Josh Drake's efforts, the PostgreSQL Day San Francisco is in
the advertising mailer for LinuxWorldExpo San Francisco. This means
that it's just been advertised to about 100,000 people. Yaaay!

Anyway, that probably means its time to start planning this event. I'll
be putting it on the calendar and soliciting talks soon; who wants to be
on the event committee?

--Josh


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

Re: [BUGS] statement_timeout and crosstab

(1) Sorry, automatic by e-mail client, disabled.

(2) I`m just trying to help to make postgresql better, my problem was
solved at app level with asyncronous query and controlling the timeout
by itself. I believe that this is a way of rewarding the dedication and
commitment of all of you.

(3) I got a sample usage of crosstab at this site:

http://www.postgresonline.com/journal/index.php?/archives/14-CrossTab-Queries-in-PostgreSQL-using-tablefunc-contrib.html.

(4) Create tables and data:

CREATE TABLE inventory
(
item_id serial NOT NULL,
item_name varchar(100) NOT NULL,
CONSTRAINT pk_inventory PRIMARY KEY (item_id),
CONSTRAINT inventory_item_name_idx UNIQUE (item_name)
)
WITH (OIDS=FALSE);

CREATE TABLE inventory_flow
(
inventory_flow_id serial NOT NULL,
item_id integer NOT NULL,
project varchar(100),
num_used integer,
num_ordered integer,
action_date timestamp without time zone
NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT pk_inventory_flow PRIMARY KEY (inventory_flow_id),
CONSTRAINT fk_item_id FOREIGN KEY (item_id)
REFERENCES inventory (item_id)
ON UPDATE CASCADE ON DELETE RESTRICT
)
WITH (OIDS=FALSE);

CREATE INDEX inventory_flow_action_date_idx
ON inventory_flow
USING btree
(action_date)
WITH (FILLFACTOR=95);

INSERT INTO inventory(item_name) VALUES('CSCL (g)');
INSERT INTO inventory(item_name) VALUES('DNA Ligase (ul)');
INSERT INTO inventory(item_name) VALUES('Phenol (ul)');
INSERT INTO inventory(item_name) VALUES('Pippette Tip 10ul');


INSERT INTO inventory_flow(item_id, project, num_ordered, action_date)
SELECT i.item_id, 'Initial Order', 10000, '2007-01-01'
FROM inventory i;

--Similulate usage
INSERT INTO inventory_flow(item_id, project, num_used, action_date)
SELECT i.item_id, 'MS', n*2,
'2007-03-01'::timestamp + (n || ' day')::interval + ((n + 1) ||
' hour')::interval
FROM inventory As i CROSS JOIN generate_series(1, 250) As n
WHERE mod(n + 42, i.item_id) = 0;

INSERT INTO inventory_flow(item_id, project, num_used, action_date)
SELECT i.item_id, 'Alzheimer''s', n*1,
'2007-02-26'::timestamp + (n || ' day')::interval + ((n + 1) ||
' hour')::interval
FROM inventory as i CROSS JOIN generate_series(50, 100) As n
WHERE mod(n + 50, i.item_id) = 0;

INSERT INTO inventory_flow(item_id, project, num_used, action_date)
SELECT i.item_id, 'Mad Cow', n*i.item_id,
'2007-02-26'::timestamp + (n || ' day')::interval + ((n + 1) ||
' hour')::interval
FROM inventory as i CROSS JOIN generate_series(50, 200) As n
WHERE mod(n + 7, i.item_id) = 0 AND i.item_name IN('Pippette Tip
10ul', 'CSCL (g)');


( 5 ) Here's the problem (it returns without breaking by timeout):

set statement_timeout = 1;

SELECT mthreport.*
FROM
crosstab('SELECT i.item_name::text As row_name,
to_char(if.action_date, ''mon'')::text As bucket,
SUM(if.num_used)::integer As bucketvalue
FROM inventory As i INNER JOIN inventory_flow As if
ON i.item_id = if.item_id
AND action_date BETWEEN date ''2007-01-01'' and date ''2007-12-31
23:59''
GROUP BY i.item_name, to_char(if.action_date, ''mon''),
date_part(''month'', if.action_date)
ORDER BY i.item_name',
'SELECT to_char(date ''2007-01-01'' + (n || '' month'')::interval,
''mon'') As short_mname
FROM generate_series(0,11) n')
As mthreport(item_name text, jan integer, feb integer, mar integer,
apr integer, may integer, jun integer, jul integer,
aug integer, sep integer, oct integer, nov integer,
dec integer);

( 6 ) A big THANK YOU, for all postgresql team.

regards,
tiago jacobs

Tom Lane escreveu:
> "Tiago D. Jacobs - iMDT" <tiago@imdt.com.br> writes:
>
> (1) Please do not post HTML.
>
> (2) Your example fails instantly with
> ERROR: a column definition list is required for functions returning "record"
> I'm prepared to believe that there's a loop in crosstab() that fails to
> check for interrupts reasonably often, but it's not obvious where. You
> need to provide a complete working test case if you want the problem
> investigated.
>
> regards, tom lane
>


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

Re: [HACKERS] bloated heapam.h

Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>
>> Others are more conflictive. For example syncscan.c is keeping the
>> prototypes for its own functions on heapam.h. Also pruneheap.c and
>> rewriteheap.c. As a result, not only themselves need to include
>> heapam.h (without any other need for it), but they force some other
>> files into including heapam.h to get their prototypes. I think this is
>> a mistake; I propose splitting those prototypes to their own files, and
>> #including those as appropriate.
>>
>> Objections?
>
> I have similar thing in my TODO list. See my patch from March commit fest
> and discussion. I need solve two main issues - remove postgres.h from
> binaries and keep history of structures (for pg_upgrade project).

Yeah, I remember that. Is there any progress on that front?

BTW I noticed that I was a bit careless in the description. rewriteheap
already has its own rewriteheap.h file; and there's no point at all in
separating pruneheap.c declarations into another file.

The one that makes a bit more sense is a new syncscan.h. And there are
a lot of things in heapam.h that actually correspond to tuple
manipulation (heap_form_tuple and so on), so perhaps a new header file
would be appropriate, but there's already htup.h which contains
tuple-related stuff.

--
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] Posting to hackers and patches lists

On Sat, May 10, 2008 at 10:55:57AM +0100, Gregory Stark wrote:
> "Zdenek Kotala" <Zdenek.Kotala@Sun.COM> writes:
> > Gregory Stark napsal(a):
> >> "Josh Berkus" <josh@agliodbs.com> writes:
> >>
> >>> How about hacking together a simple patch tracker instead, as
> >>> Bruce suggested? I've never found e-mail to be a particularly
> >>> good way to track patches.
> >>
> >> The thing is that we don't just want to "track" patches. We want
> >> to talk about patches.
> >
> > I think we want to have both. If you have big patch you don't want
> > go through all patch again and again when new version is released
> > with only few changes. If you are able to have diff between two
> > patch versions you are able preform easy check if all comments are
> > already fixed.
>
> Ah, that's not something a patch tracker or a mailing list would
> solve. There is a tool that would solve this -- a revision control
> system.

There's already an official git repository, and it plays nicely with
the official CVS it sits on top of :)

http://git.postgresql.org/

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

[COMMITTERS] libpqtypes - libpqtypes: update README docs

Log Message:
-----------
update README docs

Modified Files:
--------------
libpqtypes:
INSTALL (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/INSTALL.diff?r1=1.1&r2=1.2)

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

[COMMITTERS] libpqtypes - libpqtypes: spelling error in PQparamExec.3 man page

Log Message:
-----------
spelling error in PQparamExec.3 man page

Modified Files:
--------------
libpqtypes/docs/man3:
PQparamExec.3 (r1.3 -> r1.4)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/docs/man3/PQparamExec.3.diff?r1=1.3&r2=1.4)

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

[PERFORM] Re: Query Optimization with Kruskal’s Algorithm

On May 8, 2:09 am, a...@purefiction.net ("Alexander Staubo") wrote:
> On 5/7/08, Tarcizio Bini <tarcizi...@c3sl.ufpr.br> wrote:
>
> > I'm working on optimizing queries using the Kruskal algorithm
> > (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4318118).
>
> That paper looks very interesting. I would love to hear what the
> PostgreSQL committers think of this algorithm.
>
> Alexander.
>
> --
> Sent via pgsql-performance mailing list (pgsql-performa...@postgresql.org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-performance

I also would like to hear from them. But seems like the thread is
loosed in tonn of other threads.

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

[JDBC] JDBC types vs postgres types correspondation

Dear list,

We have a problem with the JDBC types. We need to find out the correspondation table between jdbc types and postgresql type.
What we're trying to do is to build a CREATE TABLE query where a column has to be of type "character varying", but we're not able to find the corresponding JDBC type.
Here you have the related part of out Java code:

*******************************************************************************************************************
    public String getTargetType (int jdbctype) throws SQLException {
        targettype.beforeFirst(); // targettype is the ResultSet obtained by DatabaseMetaData
        while (targettype.next()) {
            if (targettype.getInt ("DATA_TYPE") == jdbctype) {
                return targettype.getString("TYPE_NAME");
            }
        }
        return null;
    }

    public void creaTabellaCommesse () {
        String sql = "CREATE TABLE Commesse (";
       
        try {
            String dbChar = getTargetType(Types.VARCHAR);
            sql += "ID_Commessa " + getTargetType(Types.INTEGER) + " PRIMARY KEY, ";
            sql += "Prodotto " + dbChar + ", ";
            sql += "Finitura " + dbChar + ", ";
            sql += "DenominazioneUso " + dbChar + ", ";
            sql += "DestinazioneUso " + dbChar + ", ";
            sql += "PaeseDiDestinazione " + dbChar + ")";
           
            int n = st.executeUpdate(sql); //the Statement st is allocated elsewhere of my code
        }
        catch (SQLException ex) {
            eccezione (ex);
        }
    }
****************************************************************************************************************

The jdbc driver we downloaded is postgresql-8.3-603.jdbc4.jar; the postgresql server version we installed is 8.3.
Our code doesn't provide me any error, but the table columns are of type "name", which is too short in length to be effective in storing the most part of our program string.
Any idea of what we're missing?

Thanks a lot for your support.
Regards,
Marco and Rita.

[HACKERS] Rethinking dependency traversal during DROP

I promise I won't expend any real effort on this until after the
commitfest is over, but ...

While working on the recently committed constraints patch, I got annoyed
by the way in which DROP CASCADE frequently emitted "noise" messages.
For instance:

regression=# create table p1 (f1 int);
CREATE TABLE
regression=# create table c1 (f2 int check (f2>0)) inherits (p1);
CREATE TABLE
regression=# drop table p1 cascade;
NOTICE: drop cascades to table c1
NOTICE: drop cascades to constraint c1_f2_check on table c1
DROP TABLE

The check constraint is auto-dependent on c1, so really the second
message shouldn't be there. The reason it is there is that the
constraint also has a normal dependency on c1.f2, and if this pg_depend
link is traversed first (which seems to almost always be the case)
then you get the message. The findAutoDeletableObjects() scan that is
supposed to prevent this behavior does not, because it only goes as far
as the objects that are directly auto- or internal-dependent on the
original target object (ie, p1).

I thought about fixing this by doing a new findAutoDeletableObjects()
scan whenever we recurse, adding-on new objects to not complain about.
This sort of works; I attach a test patch that does that, and the
regression test output changes it induces, which seem to be all to
the good. But it's a pretty ugly idea for a number of reasons:

1. With this patch, every single call to recursiveDeletion is preceded
by findAutoDeletableObjects, which at the very least cries out for
refactoring.

2. The above observation puts the final nail in the coffin of the
original design idea, which was to do one recursive traversal of
pg_depend links during DROP. It's indisputable that we now must
traverse the entire link tree twice (at least!), and the cost of
doing that seems annoying, especially when we are sitting there
building various lists of the objects in memory anyway.

3. We have got various open bug reports centered around the fact
that a cascaded DROP takes locks too late:
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php
http://archives.postgresql.org/pgsql-bugs/2007-03/msg00143.php
http://archives.postgresql.org/pgsql-bugs/2007-12/msg00188.php
If we are going to be forced into a two-pass approach, we really
ought to try to solve those issues at the same time.

So the idea I am toying with goes like this:

1. First, recursively scan the pg_depend tree to find every object that
would have to be deleted in order to drop the initial target object(s).
Take out locks on objects that are of lockable types before scanning for
their referencing objects, but don't do anything else yet. Build an
ObjectAddresses list in memory of the objects-to-drop, and annotate each
entry with flags showing how we got to it (ie, via normal, auto, or
internal dependency links).

2. Scan the ObjectAddresses list and issue notices about any objects
that are reachable only via normal dependencies. If there are any,
and it's not a CASCADE drop, error out. (This means we will fail in
such a case after expending quite a lot less work than we do now.)

3. Scan the ObjectAddresses list back-to-front and perform the
deletions. The back-to-front scan ensures dependent objects are deleted
before depended-on ones, which is critical in a number of cases.

I am not entirely certain that a back-to-front traversal is sufficient:
there may need to be some kind of sorting step, or maybe we should just
continue to drive the deletion pass off scans of pg_depend, seeing that
we'll have to do those anyway to delete the pg_depend entries. So this
is just a back-of-the-napkin sketch of how it might work.

Comments?

regards, tom lane

Re: [HACKERS] Setting a pre-existing index as a primary key

Tom Lane wrote:

> Apparently your definition of "easy" depends entirely on
> keystrokes and not at all on memory/cognitive burden.

I was trying to remove one opportunity for human error, which is tied to
memory and cognitive burden. It is very easy to fat finger something. Is
it a critical error? No. Is it obnoxious to have to go back and fix it,
yes. When you are going back to fix, are you going to be grousing about
how PostgreSQL doesn't make this easier, maybe.

>
> IMHO a utility command should do one easily-explained thing. The fewer
> options the better.

I would agree with this except that by my definition your argument
fails. You are adding options by not allowing a sane default that
applies consistency to the database. I believe this will cause more
trouble than having the limitation in the first place.

Anyway, I have made my arguments. I believe we are still in the middle
of a commit fest.

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: [GENERAL] Returning RECORD from PGSQL without custom type?

On Sat, 10 May 2008 02:36:50 -0500
"D. Dante Lorenso" <dante@lorenso.com> wrote:

> Instead of doing this:
>
> CREATE OR REPLACE FUNCTION "my_custom_func" (in_value bigint)
> RETURNS SETOF record AS
> $body$
> ...
> $body$
> LANGUAGE 'plpgsql' VOLATILE;

What's the problem with the above?
You don't like to specify the returned type in each "caller"?

then

CREATE OR REPLACE FUNCTION "my_custom_func" (in_value bigint
out ret1 int, out ret2 text, out ret3 float
)
RETURNS SETOF record AS
$body$
declare
row record;
begin
for ...

ret1:=row.col1;
ret2:=row.col2;
if(row.col3)<7 then
ret3:=row.col3;
else
ret3:=0;
end if;
...
$body$
LANGUAGE 'plpgsql' VOLATILE;

then you can call
select ret2 from my_custom_func(100) where ret1<12;

> I'd like to be able to do this:
>
> CREATE OR REPLACE FUNCTION "my_custom_func" (in_value bigint)
> RETURNS SETOF (col1name BIGINT, col2name TEXT, ...) AS
> $body$
> ...
> $body$
> LANGUAGE 'plpgsql' VOLATILE;
>

it looks similar to the above...

> RETURN NEXT OUT;
>
> OUT.col1name := 12345;
> RETURN NEXT OUT;
>
> SELECT 12345, 'sample'
> INTO OUT.col1name, OUT.col2name;
> RETURN NEXT OUT;

I'm not sure if you can...

> Does this feature request make sense to everyone? It would make
> programming set returning record functions a lot easier.

yeah it could be a nice shortcut to define types "locally".

Once you call "OUT" the type, you could avoid the ret1:=row.


--
Ivan Sergio Borgonovo
http://www.webthatworks.it


--
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] constraint exclusion analysis caching

Stephen Frost wrote:
>
>> (BTW, why does your MUA set Mail-Followup-To: (and do it badly, what's
>> more) ?)
>>
>
> I'm amazed at the number of people who ask me this.. Guess it's just
> different for different communities. Basically, I like to keep my mail
> in the different folders it belongs in, so I'd rather get responses to
> my emails through the list than directly to me. Additionally, I don't
> really need to get two copies of every email sent to me on a mailing
> list.
>

I am amazed that you don't see that what your MUA is doing is actually
both wrong and that it inconveniences people.

For example, because it put *my* address in the list for your message
above, it caused my MUA quite correctly to add a To: line to myself,
which I certainly didn't want to do.

And it's completely unnecessary. For example, I have set my majordomo
preferences for the postgresql.org lists not to send me copies of emails
where I am also in the To: or Cc: lines. After doing that I get no
duplicates.

And I don't casue anyone else to have to edit the addresses when they
reply to my mail.

If you want to ensure that you reply to a list, use an MUA that has a
reply-to-list command - I see you use mutt, which has such a command IIRC.

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

[COMMITTERS] pgsql: Backpatch fixes for contrib makefiles.

Log Message:
-----------
Backpatch fixes for contrib makefiles.

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql/src/tools/msvc:
Mkvcbuild.pm (r1.25.2.2 -> r1.25.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/tools/msvc/Mkvcbuild.pm?r1=1.25.2.2&r2=1.25.2.3)

--
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] Setting a pre-existing index as a primary key

"Joshua D. Drake" <jd@commandprompt.com> writes:
> As a counter point, I don't see any reason to make the DBA's life
> harder. Sure it is just one step but it is a human step, prone to error
> and taking more time than it should. Why not just make it easy?

I don't see that decorating infrequently-used statements with bizarre
options that duplicate the functionality of other commands is "making it
easy". Apparently your definition of "easy" depends entirely on
keystrokes and not at all on memory/cognitive burden.

IMHO a utility command should do one easily-explained thing. The fewer
options the better.

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] Setting a pre-existing index as a primary key

Joshua D. Drake wrote:
> Tom Lane wrote:
>
>>> Well it should be optional but it would be nice if we had the option
>>> to have it renamed per the default... meaning the same output if I
>>> were to do this:
>>
>> If you want that, you can rename the index (either before or
>> afterwards).
>> I don't see any reason to clutter the make-constraint-from-index command
>> with questions of renaming.
>
> As a counter point, I don't see any reason to make the DBA's life
> harder. Sure it is just one step but it is a human step, prone to
> error and taking more time than it should. Why not just make it easy?
> Especially when the easy isn't sacrificing data integrity or quality
> of product?
>
>
>

Because that's not the basis on which we decide to add features. You
need to asses the code complexity, the potential benefit and number of
likely users. In this case, the amount of code required for what would
be nothing more than syntactic sugar for what is in any case a very
simple statement makes me agree with Tom.

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: [COMMITTERS] pgsql: Remaining pieces of fix for contrib makefiles

adunstan@postgresql.org (Andrew Dunstan) writes:
> Remaining pieces of fix for contrib makefiles

Don't forget 8.3 needs it too.

regards, tom lane

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

Re: choiche of function language was: Re: [GENERAL] dynamic procedure call

I wrote:
> We've poked a few loopholes in the strong typing over the years
> --- the whole business of EXECUTE versus direct evaluation of a
> query can be seen as allowing weak typing for EXECUTE'd queries.
> But it's still the language's design center.

Rereading that, it suddenly struck me that Pavel's recent addition of
USING to EXECUTE provides a klugy way to get at a run-time-determined
member of a row variable, which seems to be the single most-requested
facility in this area. I put together the following test case, which
tries to print out the values of fields selected by trigger arguments:

create or replace function foo() returns trigger as $$
declare
r record;
begin
for i in 1 .. tg_argv[0] loop
execute 'select $1 . ' || tg_argv[i] || ' as x'
into r using NEW;
raise notice '% = %', tg_argv[i], r.x;
end loop;
return new;
end $$ language plpgsql;

create table tab(f1 int, f2 text, f3 timestamptz);

create trigger footrig before insert on tab for each row
execute procedure foo (3,f1,f2,f3);

insert into tab values(42, 'foo', now());

(BTW, in this example it's truly annoying that TG_ARGV[] isn't a
"real" array that you can use array_lower/array_upper on. Maybe
that is worth fixing sometime.)

Unfortunately this doesn't quite work, because plpgsql is resolutely
strongly typed:

NOTICE: f1 = 42
ERROR: type of "r.x" does not match that when preparing the plan
CONTEXT: PL/pgSQL function "foo" line 6 at RAISE

IOW, it gets through the first cycle of the loop okay, but in the
second one the "r.x" subexpression has already been planned on the
expectation that r.x is of type int.

You can get around this if you are willing to coerce all possible
results to the same type, eg text:

create or replace function foo() returns trigger as $$
declare
t text;
begin
for i in 1 .. tg_argv[0] loop
execute 'select cast ( $1 . ' || tg_argv[i] || ' as text)'
into t using new;
raise notice '% = %', tg_argv[i], t;
end loop;
return new;
end $$ language plpgsql;

et voila:

NOTICE: f1 = 42
NOTICE: f2 = foo
NOTICE: f3 = 2008-05-10 11:38:33.677035-04

So, it's a hack, and it relies on a feature that won't be out till 8.4,
but it *is* possible ...

regards, tom lane

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

[ADMIN] Access Priviledges among multiple users (roles).


Hi ,

I am screwed up in permissions related issue !!!!!!!!

Senario:
==========
User1 : gpadmin (DBA user)
user2: BIUSER ( reporting user)-------------this is not a OS user, rather a DB login ROLE.

all table deployed in gpadmin user, having parent table and lots of child tables.

example:

1) SMS (parent table)
2) SMS_child_1
    SMS_child_2
.........
SMS_child_n

Child tables( actually partitioned tables ; one child table for each day) inherit from parent tables.

now, there is another Reporting user : "BIUSER".
This user need access to all tables of gpadmin user.

how do i grant "select" priviledges on all tables in gpadmin user to biuser in a single command, so that  current and future child tables in gpadmin tables also becomes accessible to biuser.

can anyone guide me the right method to do this ??

i done want to issue grant command for each table !








Regards,
Srikanth k Potluri
+63 9177444783(philippines)

Re: [HACKERS] Setting a pre-existing index as a primary key

Tom Lane wrote:

>> Well it should be optional but it would be nice if we had the option to
>> have it renamed per the default... meaning the same output if I were to
>> do this:
>
> If you want that, you can rename the index (either before or afterwards).
> I don't see any reason to clutter the make-constraint-from-index command
> with questions of renaming.

As a counter point, I don't see any reason to make the DBA's life
harder. Sure it is just one step but it is a human step, prone to error
and taking more time than it should. Why not just make it easy?
Especially when the easy isn't sacrificing data integrity or quality of
product?


Sincerely,

Joshua D. Drake


>
> 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: Remaining pieces of fix for contrib makefiles

Log Message:
-----------
Remaining pieces of fix for contrib makefiles

Modified Files:
--------------
pgsql/src/tools/msvc:
Mkvcbuild.pm (r1.28 -> r1.29)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/tools/msvc/Mkvcbuild.pm?r1=1.28&r2=1.29)

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

Re: choiche of function language was: Re: [GENERAL] dynamic procedure call

Ivan Sergio Borgonovo <mail@webthatworks.it> writes:
> It is clear what is at least one of the advantage of plpython or
> plperl over plpgsql, but then what are the advantages of plpgsql over
> the rest of the crowd other than resembling the language used in
> Oracle?

Others made some other comments already, but I think the issue that
is specifically concerning you is the question of strong vs weak
typing. plpgsql is designed as a strongly typed language, meaning
that the types of all objects are supposed to be predetermined and
not changing. This makes it difficult if not impossible to write stuff
that can refer to run-time-selected columns. But you get benefits in
terms of better error checking and improved performance --- a weakly
typed language could never cache any plans, not even for trivial
expressions.

We've poked a few loopholes in the strong typing over the years
--- the whole business of EXECUTE versus direct evaluation of a
query can be seen as allowing weak typing for EXECUTE'd queries.
But it's still the language's design center.

I think it'd be possible to build a weakly typed language that was
just as well integrated with SQL as plpgsql is, but it would likely
be markedly slower in use.

regards, tom lane

--
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] Setting a pre-existing index as a primary key

"Joshua D. Drake" <jd@commandprompt.com> writes:
> Tom Lane wrote:
>> Why, and exactly what would you define as "appropriate naming style"?
>> The user has always been free to pick whatever constraint name he
>> wants.

> Well it should be optional but it would be nice if we had the option to
> have it renamed per the default... meaning the same output if I were to
> do this:

If you want that, you can rename the index (either before or afterwards).
I don't see any reason to clutter the make-constraint-from-index command
with questions of renaming.

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: choiche of function language was: Re: [GENERAL] dynamic procedure call

On May 10, 2008, at 12:14 AM, Ivan Sergio Borgonovo wrote:

> On Sat, 10 May 2008 07:35:36 +0200
> "Pavel Stehule" <pavel.stehule@gmail.com> wrote:
>
>> your application different execution paths. Generally I can say, so
>> plpgsql isn't well language for this games, and better is using
>> plperl, plpython or other external language.
>
> It is clear what is at least one of the advantage of plpython or
> plperl over plpgsql, but then what are the advantages of plpgsql over
> the rest of the crowd other than resembling the language used in
> Oracle?

A much better impedance match to the database. It's designed for
doing database-ish things. The biggest advantage there is that
your datatypes are the database datatypes and your expression
parser is the sql expression parser. That makes using things like
timestamp or interval or custom database types simpler and cleaner
from pl/pgsql than from, say, pl/perl/

Cheers,
Steve


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

Re: [PATCHES] [NOVICE] encoding problems

On Fri, 9 May 2008 08:38:01 -0400
Alvaro Herrera <alvherre@commandprompt.com> wrote:

> Bruce Momjian escribió:
> > Guillaume Smet wrote:
> > > On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <bruce@momjian.us>
> > > wrote:
>
> > > As I mentioned it before, is there any chance for this fix to be
> > > backported to 8.3 branch? IMHO it's a usability regression.
> >
> > No, we don't change behaviors in back branches unless we get lots of
> > complaints, and we haven't in this case.
>
> complaints++
>

I suppose this a "Me Too" post, but Bruce Momjian invites it. You
folks take this to a level way beyond me, but I can tell you that the
idea of using spaces instead of the terminal hard tabs would solve my
problem -- I'd prefer _any_ choice of whitespace over seeing "\x09" on
the terminal.

--

Cliff Nieuwenhuis

"As long as the error messages keep changing we're making progress."

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

Re: [pgsql-es-ayuda] PGRES_FATAL_ERROR ERROR: Slony-I: setAddSequence_int(): sequence ID 67 has already been assigned

El sáb, 10-05-2008 a las 10:30 -0300, Martin Marques escribió:
> Edwin Perez Lozano escribió:
> > Buen dia
> >
> > Bueno como dice el asunto del mail .. estoy tratando de trabajar con
> > slony indico las entidades a sincronizar pero siempre me saca el mismo
> > error:
> >
> > 2008-05-10 06:40:37 COT DEBUG2 remoteWorkerThread_1: all tables for set
> > 1 found on subscriber
> > 2008-05-10 06:40:37 COT DEBUG2 remoteWorkerThread_1: copy sequence
> > "public"."auditoria_guia_secuencial_seq"
> > 2008-05-10 06:40:37 COT ERROR remoteWorkerThread_1: "select
> > "_cluster_zeus_atenea".setAddSequence_int(1, 67,
> > '"public"."auditoria_guia_secuencial_seq"', 'Sequence
> > auditoria_guia_secuencial_seq')" PGRES_FATAL_ERROR ERROR: Slony-I:
> > setAddSequence_int(): sequence ID 67 has already been assigned

Hola Martin.
>
> Algo estas haciendo mal. Parece que tenes algun problema de duplicacion
> de PK, pero es imposible saber sin la informacion replicacion.
Adjunto al correo envie el script que cree para las entidades que se van
a sincronizar.. o necesitas algo mas especifico.?¿

> Tienen PK
> las tablas o estas usando las opciones de slony (serialtables) para
> gererarlas en la replicacion?
Todas las tablas tienen llave primaria y en realidad no he utlizado esa
opcion que indicas en slony (donde podria obtener mas informacion sobre
esto que me comentas.?¿)
>
> Que hay en los logs de PG?
Buena pregunta... ya reviso.
>
>
Gracias Martin por la respuesta.

--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] PGRES_FATAL_ERROR ERROR: Slony-I: setAddSequence_int(): sequence ID 67 has already been assigned

Edwin Perez Lozano escribió:
> Buen dia
>
> Bueno como dice el asunto del mail .. estoy tratando de trabajar con
> slony indico las entidades a sincronizar pero siempre me saca el mismo
> error:
>
> 2008-05-10 06:40:37 COT DEBUG2 remoteWorkerThread_1: all tables for set
> 1 found on subscriber
> 2008-05-10 06:40:37 COT DEBUG2 remoteWorkerThread_1: copy sequence
> "public"."auditoria_guia_secuencial_seq"
> 2008-05-10 06:40:37 COT ERROR remoteWorkerThread_1: "select
> "_cluster_zeus_atenea".setAddSequence_int(1, 67,
> '"public"."auditoria_guia_secuencial_seq"', 'Sequence
> auditoria_guia_secuencial_seq')" PGRES_FATAL_ERROR ERROR: Slony-I:
> setAddSequence_int(): sequence ID 67 has already been assigned

Algo estas haciendo mal. Parece que tenes algun problema de duplicacion
de PK, pero es imposible saber sin la informacion replicacion. Tienen PK
las tablas o estas usando las opciones de slony (serialtables) para
gererarlas en la replicacion?

Que hay en los logs de PG?


--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

[COMMITTERS] libpqtypes - libpqtypes: updated README

Log Message:
-----------
updated README

Modified Files:
--------------
libpqtypes:
README (r1.3 -> r1.4)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/README.diff?r1=1.3&r2=1.4)

--
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] bloated heapam.h

Alvaro Herrera napsal(a):

> Others are more conflictive. For example syncscan.c is keeping the
> prototypes for its own functions on heapam.h. Also pruneheap.c and
> rewriteheap.c. As a result, not only themselves need to include
> heapam.h (without any other need for it), but they force some other
> files into including heapam.h to get their prototypes. I think this is
> a mistake; I propose splitting those prototypes to their own files, and
> #including those as appropriate.
>
> Objections?

I have similar thing in my TODO list. See my patch from March commit fest and
discussion. I need solve two main issues - remove postgres.h from binaries and
keep history of structures (for pg_upgrade project).

My idea is split structures and functions in separate header files.

Zdenek

http://archives.postgresql.org/pgsql-patches/2007-10/msg00197.php
http://archives.postgresql.org/pgsql-patches/2008-04/msg00149.php


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

Re: [PERFORM] plan difference between set-returning function with ROWS within IN() and a plain join

On Tue, May 6, 2008 at 11:27 AM, Frank van Vugt <ftm.van.vugt@foxi.nl> wrote:
>> > db=# explain analyse
>> > select sum(base_total_val)
>> > from sales_invoice
>> > where id in (select id from si_credit_tree(80500007));
>>
>> Did you check whether this query even gives the right answer?
>
> You knew the right answer to that already ;)
>
>> I think you forgot the alias foo(id) in the subselect and it's
>> actually reducing to "where id in (id)", ie, TRUE.
>
> Tricky, but completely obvious once pointed out, that's _exactly_ what was
> happening.

This is one of the reasons why, for a table named 'foo', I name the
columns 'foo_id', not 'id'. Also, if you prefix the id column with
the table name, you can usually use JOIN USING which is a little bit
tighter and easier than JOIN ON.

merlin

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

[pgsql-es-ayuda] PGRES_FATAL_ERROR ERROR: Slony-I: setAddSequence_int(): sequence ID 67 has already been assigned

Buen dia

Bueno como dice el asunto del mail .. estoy tratando de trabajar con
slony indico las entidades a sincronizar pero siempre me saca el mismo
error:

2008-05-10 06:40:37 COT DEBUG2 remoteWorkerThread_1: all tables for set
1 found on subscriber
2008-05-10 06:40:37 COT DEBUG2 remoteWorkerThread_1: copy sequence
"public"."auditoria_guia_secuencial_seq"
2008-05-10 06:40:37 COT ERROR remoteWorkerThread_1: "select
"_cluster_zeus_atenea".setAddSequence_int(1, 67,
'"public"."auditoria_guia_secuencial_seq"', 'Sequence
auditoria_guia_secuencial_seq')" PGRES_FATAL_ERROR ERROR: Slony-I:
setAddSequence_int(): sequence ID 67 has already been assigned
2008-05-10 06:40:37 COT WARN remoteWorkerThread_1: data copy for set 1
failed - sleep 60 seconds
WARNING: no hay una transacción en curso

Y he revisado el script y no tengo donde se repita el id 67..

Adjunto el archivo donde estan definidas las entidades..

De antemano gracias por la informacion que puedan darme.

Re: [HACKERS] Posting to hackers and patches lists

Gregory Stark napsal(a):
> "Zdenek Kotala" <Zdenek.Kotala@Sun.COM> writes:
>
>> Gregory Stark napsal(a):
>>> "Josh Berkus" <josh@agliodbs.com> writes:
>>>
>>>> How about hacking together a simple patch tracker instead, as Bruce
>>>> suggested? I've never found e-mail to be a particularly good way to track
>>>> patches.
>>> The thing is that we don't just want to "track" patches. We want to talk about
>>> patches.
>> I think we want to have both. If you have big patch you don't want go through
>> all patch again and again when new version is released with only few changes.
>> If you are able to have diff between two patch versions you are able preform
>> easy check if all comments are already fixed.
>
> Ah, that's not something a patch tracker or a mailing list would solve. There
> is a tool that would solve this -- a revision control system.

OK. I little bit confused what patch tracer should do. Is it only for tracking
discuss about patches?

> We aren't using CVS the way it's really intended. If all this development
> happened on branches then people could go look at the current version at any
> point, not just when authors decide to announce it. And people could generate
> diffs between the last time they looked at that branch and now etc.

Yeah, I discussed this with Peter E. during his Prague visit and it should be
big deal for code reviewing and new feature development.

Zdenek


--
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] "Claimed" status on Commitfest pages

On Sat, 2008-05-10 at 15:57 +1000, Brendan Jurd wrote:
> On Sat, May 10, 2008 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I see that Brendan has proposed the following definition on
> > CommitFest:Help:

> I wouldn't say I did anything so formal as proposing a definition =)
>
> Someone mentioned that a column to indicate who's handling each patch
> would be nice, so I added it. The comments in :Help were really just
> an example to explain how you might use the feature.
>
> I'm not looking to formulate commitfest procedure here (I don't have
> quite that level of hubris), just providing some tools to get the job
> done more comfortably.
>
> > I'm not too pleased with this because it suggests that "reviewing" is
> > something only one person can do at a time. What I'd like to see is
> > guidelines more along these lines:
>
> By all means, go ahead and make these changes. I think your version
> makes a lot of sense.

Certainly having a column mostly set to "nobody" isn't much use. People
want to help, but that's hard when we have no way of knowing which
patches might be ones that are considered open to general review and
which ones are Tom-only.

I added my name to a few patches only to assist with distribution of
work, so people don't waste time, not to "claim them". I figured the
only reason others hadn't done it was 'cos the coding the Wiki was
slightly fiddly.

Completely agree that there isn't/shouldn't be a single reviewer on an
item, but realistically if one of us is obviously reviewing something,
people will work on others while they do that. After that initial review
others join in to check quality. We probably do need to mark them in
some way to say "I am in the process of reviewing this", so we don't
duplicate effort (by mistake).

--
Simon Riggs
2ndQuadrant

http://www.2ndQuadrant.com


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

[GENERAL] Problem returning strings with pgsql 8.3.x

While developing PL/LOLCODE, I've found something wrong with returning
strings from LOLCODE functions using 8.3.0 or greater. Using 8.4beta
from a few days ago, for instance, a function that should return "test
string" returns
"\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F" in
pgsql (sometimes the number of \x7F characters varies). In 8.2.4 it
works fine.

Here's the code involved, from pl_lolcode_call_handler, the call
handler function for PL/LOLCODE. First, the bit that finds the
FmgrInfo structure and typioparam for the result type:

procTup = SearchSysCache(PROCOID,
ObjectIdGetDatum(fcinfo->flinfo->fn_oid), 0, 0, 0);
if (!HeapTupleIsValid(procTup)) elog(ERROR, "Cache lookup
failed for procedure %u", fcinfo->flinfo->fn_oid);
procStruct = (Form_pg_proc) GETSTRUCT(procTup);

typeTup = SearchSysCache(TYPEOID,
ObjectIdGetDatum(procStruct->prorettype), 0, 0, 0);
if (!HeapTupleIsValid(typeTup)) elog(ERROR, "Cache lookup
failed for type %u", procStruct->prorettype);
typeStruct = (Form_pg_type) GETSTRUCT(typeTup);

resultTypeIOParam = getTypeIOParam(typeTup);
fmgr_info_cxt(typeStruct->typinput, &flinfo,
TopMemoryContext); /*CurTransactionContext); */
ReleaseSysCache(typeTup);

Here's the code that converts the return value into a Datum later on
in the function:

if (returnTypeOID != VOIDOID) {
if (returnVal != NULL) {
if (returnVal->type == ident_NOOB)
fcinfo->isnull = true;
else {
SPI_push();
if (returnTypeOID == BOOLOID)
retval =
InputFunctionCall(&flinfo, lolVarGetTroof(returnVal) == lolWIN ?
"TRUE" : "FALSE", resultTypeIOParam, -1);
else {
/* elog(NOTICE,
lolVarGetString(returnVal, true)); */
retval =
InputFunctionCall(&flinfo, lolVarGetString(returnVal, true),
resultTypeIOParam, -1);
}
SPI_pop();
}
}
else {
fcinfo->isnull = true;
}
}

SPI_finish();
/* elog(NOTICE, "PL/LOLCODE ending"); */

return retval;

returnVal is an instance of the struct PL/LOLCODE uses to store its
variables. The key line in this case is the one after the
commented-out call to elog. retval is a Datum type. lolVarGetString()
returns the string value the returnVal struct represents -- I'm
certain of that thanks to gdb and other testing. All other data types
PL/LOLCODE knows about internally seem to return just fine. I'm fairly
certain I'm screwing up memory somewhere, but I can't see what I've
done wrong.

I'm glad to provide further details, but those included above are all
the ones I thought were relevant. Thanks in advance for any help you
can provide.

- Josh / eggyknap

Note: The -hackers list seemed like the place for this post, but its
list description gives instructions to try another list first, hence
the post here.

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

[pgsql-es-ayuda] ERROR: no existe la relación con OID 26795658

Buen dia todos..

Bueno estoy realizando pruebas con slony, pero el problema pasa que
cuando comienzo a sincronizar (una base de datos maestro-esclavo) y
tratan de ingresar datos por medio de la aplicacion la cual esta con la
base de datos maestra, me sale el eror del oid, para solucionar el
percanse reincio el servicio de la base de datos.. lo cual no deberia de
ser... porque sucede esto cuando utilizo el slony.. ?¿ falta algo por
configurar para evitar este error...?


De antemano agradesco la informacion que puedan darme,

--
TIP 3: Si encontraste la respuesta a tu problema, publ�cala, otros te lo agradecer�n

[ADMIN] Proposal for restoring a dump into a database with a different owner

Hi,

I have the same problem as Andreas Haumer did in this thread:
http://archives.postgresql.org/pgsql-admin/2008-01/msg00128.php -- I want to
be able to easily (i.e. programmatically) copy a database from one place to
another, changing the owners of all contained objects in the process.

While I very much appreciate Tom Lane's fast and helpful responses to
Andreas on that thread, it doesn't quite address my problem: there is no
simple, automatable 1- or 2-step process that can accomplish this (without
Andreas's (admittedly neat) trick of temporarily changing the destination
user to superuser status). The best I've been able to do is hack up a Perl
script that parses the output of pg_restore -l, directing
superuser-requiring operations to one file and non-superuser-requiring
operations to another; but afterwards the superuser-requiring operations
still have to have the owners of the objects they produce manually
reassigned.

My instincts (which could be wrong...) tell me that this is actually a
fairly common problem. So, I suggest the following enhancement to
pg_restore: add a --map-users command-line option that accepts the name of a
file containing two usernames on each line, <from> and <to>. Then (provided
-O was not specified) when producing ALTER ... OWNER TO commands, simply
replace every <from> user listed in this file with the corresponding <to>
user.

Another niggle is that the COMMENT ON DATABASE command, produced by
pg_restore when run without the -d option, always refers to the name of the
original database, which will cause an error if the new DB has a different
name. It would be nice to have an option (or other means) to remedy this.

It seems to me that these things would be pretty simple to implement and
sufficiently general to tackle this problem neatly, without opening up any
security holes (you would still need to be *some* DB superuser for the ALTER
... OWNER TO commands to work).

Does this sound sensible? If Tom or another high-ranking PostgreSQLer okays
it in principle, I suppose I could try developing a patch for pg_restore
myself. (Never done this before but there's a first time for everything...)

TIA,
Tim White

--
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] Returning RECORD from PGSQL without custom type?

Hello

there exist table returning functions patch, but newer been applied.
It's some what you need.

Why don't you use OUT variables?

try

CREATE OR REPLACE FUNCTION fce(IN value int, OUT a int, OUT b int)
RETURNS SETOF record AS $$
BEGIN
FOR i IN 1..$1 LOOP
a := i + 1; b := i + 2;
RETURN NEXT;
END LOOP;
END;
$$ LANGUAGE plpgsql IMMUTABLE:

SELECT * FROM fce(10);

http://www.postgresql.org/docs/8.3/interactive/xfunc-sql.html#XFUNC-OUTPUT-PARAMETERS

Regards
Pavel Stehule

2008/5/10 D. Dante Lorenso <dante@lorenso.com>:
> Instead of doing this:
>
> CREATE OR REPLACE FUNCTION "my_custom_func" (in_value bigint)
> RETURNS SETOF record AS
> $body$
> ...
> $body$
> LANGUAGE 'plpgsql' VOLATILE;
>
> I'd like to be able to do this:
>
> CREATE OR REPLACE FUNCTION "my_custom_func" (in_value bigint)
> RETURNS SETOF (col1name BIGINT, col2name TEXT, ...) AS
> $body$
> ...
> $body$
> LANGUAGE 'plpgsql' VOLATILE;
>
> Because this is the only function that will be returning that TYPE and I
> don't want to have to create a separate type definition just for the return
> results of this function.
>
> Maybe even more cool would be if the OUT record was already defined so that
> I could simply select into that record to send our new rows:
>
> RETURN NEXT OUT;
>
> OUT.col1name := 12345;
> RETURN NEXT OUT;
>
> SELECT 12345, 'sample'
> INTO OUT.col1name, OUT.col2name;
> RETURN NEXT OUT;
>
> Just as you've allowed me to define the IN variable names without needing
> the legacy 'ALIAS $1 ...' format, I'd like to name the returned record
> column names and types in a simple declaration like I show above.
>
> Does this feature request make sense to everyone? It would make programming
> set returning record functions a lot easier.
>
> -- Dante
>
> --
> 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

Re: choiche of function language was: Re: [GENERAL] dynamic procedure call

Hello

2008/5/10 Ivan Sergio Borgonovo <mail@webthatworks.it>:
> On Sat, 10 May 2008 07:35:36 +0200
> "Pavel Stehule" <pavel.stehule@gmail.com> wrote:
>
>> your application different execution paths. Generally I can say, so
>> plpgsql isn't well language for this games, and better is using
>> plperl, plpython or other external language.
>
> It is clear what is at least one of the advantage of plpython or
> plperl over plpgsql, but then what are the advantages of plpgsql over
> the rest of the crowd other than resembling the language used in
> Oracle?
>

SQL integration and compatibility with PostgreSQL. PL/pgSQL uses
PostgreSQL expression evaluation - so all PostgreSQL functions are
simply accessible from plpgsql. Next - plpgsql variables are
compatible (are same) with PostgreSQL internal datatypes - so you
don't need any conversion between Postgres and plpgsql.

plpgsql is best glue of SQL statements.

Pavel

> --
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
>
>
> --
> 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