PostgreSQL

Sunday, August 10, 2008

[COMMITTERS] pgscript - pgScript: Changed copyright notice

Log Message:
-----------
Changed copyright notice

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

Re: [BUGS] ALTER TABLE name RENAME TO new_name; does notworkimmediately

Gregory Stark <stark@enterprisedb.com> writes:
> On the other hand the problem does not occur if the CREATE TABLE is in the
> same session. Nor if the REINDEX DATABASE is skipped.

It appears that you have to do the RENAME TABLE in the same session as
the REINDEX DATABASE. Furthermore, the failure then persists into
subsequent sessions. There is a "yyy" entry in pg_class, but index
searches using pg_class_relname_nsp_index don't find it.

Also, I can still reproduce it with just REINDEX TABLE pg_class instead
of REINDEX DATABASE.

What I suspect is we've broken the logic that manages REINDEX applied to
pg_class itself. There's a mighty delicate dance that goes on there,
and we haven't tested it too much lately.

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: [GENERAL] foreign key restrictions

> Gregory Stark <stark@enterprisedb.com> writes:
>> I'm not sure if there's a fundamental reason why there has to be an
>> index that
>> exactly matches the foreign key or not -- offhand I can't think of one.
>
> The reason why is that the SQL spec says so:
>
> a) If the <referenced table and columns> specifies a
> <reference
> column list>, then the set of <column name>s contained
> in that <reference column list> shall be equal to the
> set of <column name>s contained in the <unique column
> list> of a unique constraint of the referenced table. Let
> referenced columns be the column or columns identified by
> that <reference column list> and let referenced column be
> one
> such column. Each referenced column shall identify a column
> of the referenced table and the same column shall not be
> identified more than once.
>
> I'm not entirely sure, but I think the restrictive definition might be
> necessary with some of the more complex options for foreign keys, such
> as MATCH PARTIAL.

I must admit, the standard is not very easy reading for me; what exactly
does the standarad mean by "<unique column list>":
1. is that a requirement for mathematical properties of that list, or
2. is that a requirement for explicit SQL UNIQUE INDEX existing over the
entire list.

Since <column list> is a <unique column list> whenever a subset of <column
list> is a <unique column list>, then if interpretation nr.1 of the
standard is OK, there is no real requirement to install (and require to
install) an additional unique constraint on the target <column list>.

-R

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

[ODBC] c type of int8 / serial8?

Hi,

I wonder what the C type of int8 / serial8 is.

If I use SQLGetTypeInfo() to get all the supported type is says that
int8 is of SQL type SQL_BIGINT. It does not show any values for serial8
but I suppose that that is a user defined type and the driver is not
required to show those (is that correct?).

If I use SQLColumns() and get the data type from that function, is says
for both int8 and serial8 that the SQL type is SQL_BIGINT. There is
however not mapping for SQL_BIGINT to a C type. There is a mapping to a
signed or unsigned 8 byte integer (SQL_C_SBIGINT or SQL_C_UBIGINT).

>From the docs
(http://www.postgresql.org/docs/8.3/interactive/datatype.html , table
8.1) I see that int8 is a "signed eight-byte integer". For serial8 it
only says "autoincrementing eight-byte integer". So I assume that int8
is actually SQL_C_SBIGINT, but I am unsure about serial8: is it signed
or unsigned?

Shouldn't both SQLGetTypeInfo and SQLColumns return SQL_C_SBIGINT for
int8, and/or return SQL_C_SBIGINT/SQL_C_UBIGINT for serial8,. depending
on the signed-ness?

TIA

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

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

Re: [GENERAL] foreign key restrictions

<rafal@zorro.isa-geek.com> wrote in message
news:64cc57edd02dabd82e3f95268aee1a67.squirrel@localhost...
> Hi All,
>
> on numerous times I had fell onto postgress complaining, that I try to
> create foreign key, pointing to a set not embraced within a unique key
> constraint.
>
> Here is the case:
>
> CREATE TABLE one (id int not null unique, info text);
> CREATE TABLE two (id int not null unique, ofone int references one(id),
> info text);
>
> now when I try to:
>
> CREATE TABLE three(one int not null, two int, info text, foreign key (one,
> two) references two (one, id));
>
> I get the following error:
> ERROR: there is no unique constraint matching given keys for referenced
> table "two"
>
> But.
>
> Since table TWO has a unique constraint on column ID, the (ID, OFONE) pair
> will also be unique, obviously.
>
> Naturaly I can, and I do, add the requested constraint to the table TWO,
> but to me it looks spurious - not providing any additional constraint
> (which is already quearanteed by unique(ID), just a 'syntax glue'.
>
> I must have missed something here. Can someone help me understand this?
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Postgresql is being faithful to the SQL standard. ISO/IEC 9075-2:2003 11.8
<referential constraint definition> says:

"If the <referenced table and columns> specifies a <reference column list>,
then there shall be a one-to-one correspondence between the set of <column
name>s contained in that <reference column list> and the set of <column
name>s contained in the <unique column list> of a unique constraint of the
referenced table such that corresponding <column name>s are equivalent."

I don't think there is any sound justification(*) for this limitation but it
is shared by other SQL DBMSs too. Most are incredibly lame when it comes to
support for multi-table constraints. The general type of constraint you are
referring to is often called an "inclusion dependency". Probably the reason
why it isn't well supported is that the optimisation of such constraints
within the limitations of SQL is potentially quite a hard problem.

(*) Note that the term "FOREIGN KEY" is misleading anyway. The constraint
that SQL calls a FOREIGN KEY is not the same as what the relational model
calls a "foreign key". In the RM, convention has it that only referential
constraints that reference candidate keys are called foreign keys whereas
SQL allows its FOREIGN KEY to reference any columns declared as unique (ie
may be a super key rather than a candidate key).

--
David Portas

--
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] foreign key restrictions

Gregory Stark <stark@enterprisedb.com> writes:
> I'm not sure if there's a fundamental reason why there has to be an index that
> exactly matches the foreign key or not -- offhand I can't think of one.

The reason why is that the SQL spec says so:

a) If the <referenced table and columns> specifies a <reference
column list>, then the set of <column name>s contained
in that <reference column list> shall be equal to the
set of <column name>s contained in the <unique column
list> of a unique constraint of the referenced table. Let
referenced columns be the column or columns identified by
that <reference column list> and let referenced column be one
such column. Each referenced column shall identify a column
of the referenced table and the same column shall not be
identified more than once.

I'm not entirely sure, but I think the restrictive definition might be
necessary with some of the more complex options for foreign keys, such
as MATCH PARTIAL.

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] Replay attack of query cancel

Tom Lane napsal(a):
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> I wonder if we can do something diffie-hellman'ish, where we have a
>> parameter exchanged in the initial SSL'ed handshake, which is later used
>> to generate new cancel keys each time the previous one is used.
>
> Seems like the risk of getting out of sync would outweigh any benefits.
> Lose one cancel message in the network, you have no hope of getting any
> more accepted.

When cancellation key is used client should explicitly ask for a new regenerated
cancel key.

Zdenek

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql

--
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] foreign key restrictions

On Sun, Aug 10, 2008 at 07:10:10AM -0700, Richard Broersma wrote:
> On Sun, Aug 10, 2008 at 1:15 AM, <rafal@zorro.isa-geek.com> wrote:
>
> > CREATE TABLE two (id int not null unique, ofone int references one(id),
> > CREATE TABLE three(one int not null, two int, info text, foreign key (one,
> > two) references two (one, id));
> >
> > Since table TWO has a unique constraint on column ID, the (ID, OFONE) pair
> > will also be unique, obviously.
> This statement is not completely true. The only part of the pair that
> is true is ID. Also there is not unique constraint on the pare. So
> there is no way to PG to build a foreing key on the pair.

Eh? If ID is unique, then (ID,OFONE) is also unique. You don't need to
add another unique constraint because they're already guarenteed to be
unique.

While I admit the table structure is a bit odd, it should be fairly
easy to support it in postgres.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Re: [GENERAL] foreign key restrictions

"Richard Broersma" <richard.broersma@gmail.com> writes:

> On Sun, Aug 10, 2008 at 1:15 AM, <rafal@zorro.isa-geek.com> wrote:
>
>> Since table TWO has a unique constraint on column ID, the (ID, OFONE) pair
>> will also be unique, obviously.
>
> This statement is not completely true. The only part of the pair that
> is true is ID. Also there is not unique constraint on the pare. So
> there is no way to PG to build a foreing key on the pair.

Uhm, afaics he's right. if ID is unique not null then <ID, OFONE> also has to
be unique. That is, there could be duplicate values of OFONE but they'll all
have different values of ID anyways.

I'm not sure if there's a fundamental reason why there has to be an index that
exactly matches the foreign key or not -- offhand I can't think of one.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

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

Re: [ADMIN] reindexdb dying with SIGPIPE on 8.2.5

On Wed, 2008-08-06 at 23:37 -0400, Tom Lane wrote:

> I'm wondering if the reindexdb is being run under a restrictive ulimit
> setting, or something else that would prevent it from just sitting and
> waiting.

I checked... there's no limits defined in /etc/security/limits.conf.
There's more weirdness here: on the same machine, one day, everything
runs through fine.
Another day, one or two DBs are reindexed and vacuumed properly, then
all successive tries fail with the mentioned SIGPIPE error.

I'll have STDOUT and STDERR redirected to a file before the call of
reindexdb now. Perhaps there's something in the console output that
helps.

> Is there anything in the kernel log at the time of the failure report?

Don't see anything except postgresql messages at that time
in /var/log/messages, and nothing at all in /var/log/secure.

Regards,
Torsten

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

Re: [pgadmin-support] How see custom types in pgAdmin?

Guillaume Lelarge wrote:

> Bill a écrit :
> > I am very new to PostgreSQL so forgive me if I am missing something
> > obvious. I have created a custom type using CREATE TYPE. Where can I
> > see my custom types in pgAdmin?
> >
>
> Have you turned Type display on ? To do so, go in menu File, item
> Options. Then click on Display tab. Go to the end of the list and
> make sure Types is checked.

Thank you. That was the problem.

--
.Bill.

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

Re: [GENERAL] foreign key restrictions

On Sun, Aug 10, 2008 at 1:15 AM, <rafal@zorro.isa-geek.com> wrote:

> CREATE TABLE two (id int not null unique, ofone int references one(id),
> CREATE TABLE three(one int not null, two int, info text, foreign key (one,
> two) references two (one, id));
>
> I get the following error:
> ERROR: there is no unique constraint matching given keys for referenced
> table "two"
>
> But.
>
> Since table TWO has a unique constraint on column ID, the (ID, OFONE) pair
> will also be unique, obviously.
This statement is not completely true. The only part of the pair that
is true is ID. Also there is not unique constraint on the pare. So
there is no way to PG to build a foreing key on the pair.

> I must have missed something here. Can someone help me understand this?

A foreign Key can only reference a field(s) that has some type of
unique constraint ( primary key or unique ).

Try this with table two:

CREATE TABLE two (
id int not null unique,
ofone int references one(id),
txt text not null,
PRIMARY KEY ( id, ofone ));

Once you've created you two field primary key, would will be able to
reference it in table three.

--
Regards,
Richard Broersma Jr.

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

--
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-de-allgemein] Erlaubte Zeichen in Datenbanknamen

Hallo Susanne,

Susanne Ebrecht schrieb:
> udono wrote:
>> Wie genau ist der Name einer Postgresdatenbank aufgebaut?
>> Folgendes habe ich schon herausgefunden:
>> Länge: maximal 63 Zeichen
>> Erlaubte Zeichen: Alpha-Nummerisch und Unterstrich (_)
>> Name muss mit einem Buchstaben beginnen.
>> Gibt es noch weitere erlaubte Zeichen oder andere Sachen die ich bei
>> der Prüfung beachten muss?
> Wenn Du wirklich auf Nummer sicher gehen und nicht das Geheule von Usern
> ertragen möchtest, weil sie unterschiedliche Client Encodings zum Login
> verwenden und das "ö" dann doch nicht erkannt wird, wie es sollte ....
> kann ich Dir raten, prüf noch auf Kleinbuchstaben ... bzw. lasse nur
> Kleinbuchstaben zu und keine reserved keywords.
> Also nur a-z + 0-9 + Unterstrich ... dann 63 Zeichen Länge, das sollte
> reichen.
Au ja, reserved keywords habe ich nicht bedacht... da wir den
Datenbanknamen quoten, sollte es aber eigentlich keine Probleme
machen, oder doch?!
Ich werde gleich mal testen ob das Probleme macht, wenn ich eine
Datenbank erstelle die "SELECT" heißt (laut
http://www.postgresql.org/docs/8.3/static/sql-keywords-appendix.html
reserved)
Es scheint keine Probleme zu geben mit einer Datenbank namens
"SELECT"...
Trotzdem Danke für den Tipp.

> Damit erreichst Du in jedem Fall, dass kein User sich beklagt, dass das
> Login nicht erkannt wird und Du ersparst Dir Zeit und Nerven dauernd den
> Usern zu erklären, wie sie Ihr Client-Encoding richtig einstellen.
Danke für die gute Tipps!

Viele Grüße Udo

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

Re: [pgsql-de-allgemein] Erlaubte Zeichen in Datenbanknamen

Hallo Laurenz,

Albe Laurenz schrieb:
> udono schrieb:
>>>> Gibt es noch weitere erlaubte Zeichen oder andere Sachen die ich bei
>>>> der Prüfung beachten muss?
> Ich glaube, Deine Beschreibung (63 alphanumerische Zeichen) ist nicht
> korrekt: es sind 64 *Bytes* (inklusive dem 0-Byte am Ende), und alle
> Zeichen sind möglich.
> Siehe bpchar_name in src/backend/utils/adt/varchar.c.
> Allerdings ist es intelligent, die Eingabe auf Kleinbuchstaben, Ziffern und
> Unterstriche zu beschränken.
Ok, da wir den Datenbanknamen immer quoten, dürfte es auch keine
Probleme bereiten die Großbuchstaben mit hinzuzunehmen. Danke für
den Tipp mit der varchar Definition.

>>> IIRC nicht, aber ich versteh nicht ganz, warum Du den Namen einer DB als
>>> Benutzereingabe prüfen willst/mußt. Der DB-Name ist doch eher, ähm,
>>> statisch.
>> Ja, bei der Software handelt es sich um ein ERP (Enterprice Resource
>> Planning) Tool für kleine und mittelgroße Unternehmen.
>> Wenn man eine neue einzelne Firma anlegt, dann werden alle Daten in
>> eine Postgresdatenbank eingefügt. Deren Name muss der Administrator
>> angeben um sie neu erstellen zu lassen. Wir haben diesen Dialog in
>> das GUI gelegt, um die Konfiguration zu vereinfachen.
>> Bei der Eingabe des Datenbank-Namens wird gleich auf Validität
>> geprüft. (Also es sind nur alpha-nummerische Zeichen erlaubt und
>> Unterstrich, das erste Zeichen muss ein Buchstabe sein, die Anzahl
>> der eingegebenen Zeichen ist auf 63 begrenzt.) Quasi
>> Fehlervermeidung, statt Fehlermeldung...
> Ein Bedenken gegen das Design möchte ich kundtun:
> Das bedeutet, daß das Programm mit einem User mit hohen Privilegien
> (CREATEDB oder gar SUPERUSER) an die Datenbank verbunden sein muß.
Nur dann wenn du das möchtest. Im Prinzip legt man sich einen
Datenbankuser an, der CREATEDB Rechte bekommt oder auch nicht, wenn
man wie von Dir angeregt, das Erstellen einer Datenbank aus dem GUI
vermeiden möchte.
Für den Betrieb der Software ist es auch nicht nötig, über Datenbank
Superuser-Rechte zu verfügen.

> Vielen Leuten macht das vielleicht nichts aus, aber es gibt Menschen
> (und Unternehmen), für die sowas ein Ausschließungsgrund für eine
> Software ist.
Ja, das mag sein. Aber es gibt keinen Zwang seinen Datenbankbenutzer
mit Superuser- oder createdb Rechten auszustatten. Nur wenn man über
die GUI Datenbanken anlegen möchte, braucht man diese Rechte.

Aber danke für den Hinweis, ich hab mir eine Notiz gemacht, in der
Installationanleitung auf die entstehenden Sicherheitsprobleme
hinzuweisen, wenn Datenbankbenutzer über CREATEDB oder gar SUPERUSER
Rechte verfügen. Das wird besonders dann kritisch, wenn noch weitere
Portgresdatenbanken für andere Zwecke benutzt werden.

> Warum kann das nicht einfach ein neues Schema statt einer neuen
> Datenbank sein?
Schema haben wir noch nicht implementiert. Wir benutzen momentan
noch einen selbstgestrickten ORM (aus TinyERP) den wir bis Ende
nächsten Jahres durch SQL-Alchemie und Elixir ersetzen wollen. Ich
denke dann ist der Zeitpunkt gekommen, Schema zu implementieren.

Vielen Dank für Deine guten Tipps!

Schöne Grüße

Udo Spallek

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

Re: [GENERAL] [Pgpool-general] Trying to switch from PgPool1 to PgPool2

On Sun, August 10, 2008 3:03 pm, Henry wrote:
>
> I scratched around some more, found doc/pgpool-en.html and my ignorance
> has been somewhat lessened.

oi, wrong list /blushes

I really should *not* use multi-users under one login in squirrelmail...

--
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] [Pgpool-general] Trying to switch from PgPool1 to PgPool2

I scratched around some more, found doc/pgpool-en.html and my ignorance
has been somewhat lessened.

My previous config was almost right except for:

pgpool2_hostname = ''
#backend_data_directory0
#backend_data_directory1

and my Linux distro had assigned hostname 'slave1' to localhost, on which
Pg wasn't LISTENing at time... a deal-killer :P

Regards
Henry

--
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] Replay attack of query cancel

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> I wonder if we can do something diffie-hellman'ish, where we have
>> a parameter exchanged in the initial SSL'ed handshake, which is
>> later used to generate new cancel keys each time the previous one
>> is used.

Tom> Seems like the risk of getting out of sync would outweigh any
Tom> benefits. Lose one cancel message in the network, you have no
Tom> hope of getting any more accepted.

That's easily solved: when the client wants to do a cancel, have it
send, in place of the actual cancel key, an integer N and the value
HMAC(k,N) where k is the cancel key. Replay is prevented by requiring
the value of N to be strictly greater than any previous value
successfully used for this session. (Since we already have md5 code,
HMAC-MD5 would be the obvious choice.)

Migration to this could probably be handled without a version change
to the protocol, by defining a new SecureCancelRequest message and a
GUC to control whether the old CancelRequest message is accepted or
ignored. The key length for the cancel key can be increased with a
minor-version change to the protocol (if client asks for protocol 3.1,
send it a longer key, otherwise a shorter one).

--
Andrew (irc:RhodiumToad)

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

Re: [pgadmin-hackers] Support for integrated tsearch configuration

Dave Page a écrit :
> On Fri, Aug 1, 2008 at 11:05 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>> I worked three days on it. The fourth was more about testing it on different
>> platforms (GTK, Windows, Mac). Now, It's working. I don't attach the patch
>> because it's really big, but here is a URL to get it compressed:
>
> Cool :-). The usual list of random thoughts....
>
> - Should we call objects 'FTS xxxx'? All the 'Text Search xxxx' labels
> look a little long.
>

Fixed. I put FTS on all menu items.

> - There are some tokens to add to the ctlSQLBox list - at least
> GETTOKEN, LEXTYPES, HEADLINE, INIT, LEXIZE
>

I suppose this is for highlighting the Text Search keywords?

I have a few questions about this. There's a wxString that lists all
PL/pgsql specific keywords. Should I do the same with Text Search ones?

Why are the PL/pgsql specific keywords out of the pgadmin/db/keywords.c
and pgadmin/include/parser/keywords.h files? And why are the
EnterpriseDB specific keywords in these files and not in a wxString like
the PL/pgsql ones?

Here are the FTS keywords I need to add:
* gettoken, lextypes, headline (FTS Parser)
* init, lexize (FTS Template)

These FTS keywords are already available:
* parser (FTS Configuration)
* template (FTS Dictionary)
* start, end (FTS Parser)

In the new patch, I'm using another wxString to make it work like the
PL/pgsql keywords.

> - There is a little inconsistency in the RE-SQL formatting - for a
> template for example we have:
>
> CREATE TEXT SEARCH TEMPLATE fred (
> INIT = dsimple_init,
> LEXIZE = dsimple_lexize);
>
> and for a dictionary:
>
> CREATE TEXT SEARCH DICTIONARY fred (
> TEMPLATE = "simple"
> );
>
> Note the ); position.
>

You're right. It's fixed to follow the second one.

> - I got a crash when trying to create a config with no tokens.
>
> 0 pgAdmin3-Debug 0x00021b63
> wxArrayString::GetCount() const + 9 (arrstr.h:144)
> 1 pgAdmin3-Debug 0x000fed06
> dlgTextSearchConfiguration::GetSql() + 1634
> (dlgTextSearchConfiguration.cpp:346)
> 2 pgAdmin3-Debug 0x000cbf7f
> dlgProperty::OnOK(wxCommandEvent&) + 335 (dlgProperty.cpp:759)
> ...
>

Fixed. I did so many tests that I didn't do this obvious one :/

> - The Dictionaries textbox is oddly sized on the Tokens tab of the
> Configuration.
>

Some explanations on the Dictionaries textbox. I wanted to have a real
textbox, so that anyone can type what they want in it (moreover, in the
order they want to have the dictionaries) and so that, if they choose
something in the combobox, it won't replace the actual content of the
textbox.

So, I shrinked the combobox to the lowest I can, so that users can't see
the text of the combobox, and I added a textbox before the combo box.
I'm not sure this is the best way to do it. I'm a bit afraid of some UI
issues but I didn't see one at the moment. And size seems good to me.

Can you send me a screenshot of your issue? Thanks.

> - The dialogue boxes default to different sizes. They should all be
> consistently sized.
>

Fixed. Unfortunately, now, the default size is also the minimum size.

> - Don't forget to add new headers to precomp.h.
>

Done.

> I only gave the code a cusory glance - you've got lot's of pgAdmin
> experience now so I trust that it's all as clean as the bits I looked
> at :-)
>
> Overall, looks pretty good :-)
>

Thanks :)

New patch on:
http://developer.pgadmin.org/~guillaume/fts_20080810.patch.bz2

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

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

Re: [BUGS] ALTER TABLE name RENAME TO new_name; does notworkimmediately

"Alvaro Herrera" <alvherre@commandprompt.com> writes:

>> > I could not reproduce it here, but didn't try very hard.
>>
>> Did you try running the script he provided? It happened for me first try.
>
> Yep. No luck. I didn't try changing the args in generate_series though.
>
> How many CPUs are you running this on? My system has 2.

Huh, I've been able to simplify the reproducing script somewhat and still
trigger the bug. It is *not* necessary to run the table rename and the column
rename in the same transaction. That means it's *not* a problem with a missing
CommandCounterIncrement() or anything like that. Even at transaction end the
cache entry isn't being invalidated up if that's the cause.

Also, as expected the size of the table is irrelevant.

On the other hand the problem does not occur if the CREATE TABLE is in the
same session. Nor if the REINDEX DATABASE is skipped.

#!/bin/sh

/usr/local/pgsql/bin/dropdb bug
/usr/local/pgsql/bin/createdb bug

/usr/local/pgsql/bin/psql -X bug << EOF

CREATE TABLE xxx (id SERIAL, col1 TEXT, col2 TEXT);

EOF

/usr/local/pgsql/bin/psql -e -X bug << EOF

REINDEX DATABASE bug;

ALTER TABLE xxx RENAME TO yyy;
ALTER TABLE yyy RENAME COLUMN col1 TO colA;
ALTER TABLE yyy RENAME COLUMN col2 TO colB;

EOF

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

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

[GENERAL] foreign key restrictions

Hi All,

on numerous times I had fell onto postgress complaining, that I try to
create foreign key, pointing to a set not embraced within a unique key
constraint.

Here is the case:

CREATE TABLE one (id int not null unique, info text);
CREATE TABLE two (id int not null unique, ofone int references one(id),
info text);

now when I try to:

CREATE TABLE three(one int not null, two int, info text, foreign key (one,
two) references two (one, id));

I get the following error:
ERROR: there is no unique constraint matching given keys for referenced
table "two"

But.

Since table TWO has a unique constraint on column ID, the (ID, OFONE) pair
will also be unique, obviously.

Naturaly I can, and I do, add the requested constraint to the table TWO,
but to me it looks spurious - not providing any additional constraint
(which is already quearanteed by unique(ID), just a 'syntax glue'.

I must have missed something here. Can someone help me understand this?

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

Sunday, August 10, 2008

Blog Archive