[PATCHES] implement prepared queries in plperl
--
Sincerely,
Dmitry Karasik
diff -rcN plperl.cvs/SPI.xs plperl.0/SPI.xs
*** plperl.cvs/SPI.xs Thu Oct 27 12:34:29 2005
--- plperl.0/SPI.xs Thu Dec 8 10:35:38 2005
***
*** 146,150
--- 146,226
OUTPUT:
RETVAL
+ SV*
+ spi_spi_prepare(query, ...)
+ char* query;
+ CODE:
+ int i;
+ SV** argv;
+ if (items < 1)
+ Perl_croak(aTHX_ "Usage: spi_prepare(query, ...)");
+ argv = ( SV**) palloc(( items - 1) * sizeof(SV*));
+ if ( argv == NULL)
+ Perl_croak(aTHX_ "spi_prepare: not enough memory");
+ for ( i = 1; i < items; i++)
+ argv[i - 1] = ST(i);
+ RETVAL = plperl_spi_prepare(query, items - 1, argv);
+ pfree( argv);
+ OUTPUT:
+ RETVAL
+
+ SV*
+ spi_spi_exec_prepared(query, ...)
+ char * query;
+ PREINIT:
+ HV *ret_hash;
+ CODE:
+ HV *attr = NULL;
+ int i, offset = 1, argc;
+ SV ** argv;
+ if ( items < 1)
+ Perl_croak(aTHX_ "Usage: spi_exec_prepared(query,
[\\%%attr,] [EMAIL PROTECTED]");
+ if ( items > 1 && SvROK( ST( 1)) && SvTYPE( SvRV( ST( 1))) ==
SVt_PVHV) {
+ attr = ( HV*) SvRV(ST(1));
+ offset++;
+ }
+ argc = items - offset;
+ argv = ( SV**) palloc( argc * sizeof(SV*));
+ if ( argv == NULL)
+ Perl_croak(aTHX_ "spi_exec_prepared: not enough
memory");
+ for ( i = 0; offset < items; offset++, i++)
+ argv[i] = ST(offset);
+ ret_hash = plperl_spi_exec_prepared(query, attr, argc, argv);
+ RETVAL = newRV_noinc((SV*)ret_hash);
+ pfree( argv);
+ OUTPUT:
+ RETVAL
+
+ SV*
+ spi_spi_query_prepared(query, ...)
+ char * query;
+ CODE:
+ int i;
+ SV ** argv;
+ if ( items < 1)
+ Perl_croak(aTHX_ "Usage: spi_query_prepared(query,
[EMAIL PROTECTED]");
+ argv = ( SV**) palloc(( items - 1) * sizeof(SV*));
+ if ( argv == NULL)
+ Perl_croak(aTHX_ "spi_query_prepared: not enough
memory");
+ for ( i = 1; i < items; i++)
+ argv[i - 1] = ST(i);
+ RETVAL = plperl_spi_query_prepared(query, items - 1, argv);
+ pfree( argv);
+ OUTPUT:
+ RETVAL
+
+ void
+ spi_spi_freeplan(query)
+ char *query;
+ CODE:
+ plperl_spi_freeplan(query);
+
+ void
+ spi_spi_cursor_close(cursor)
+ char *cursor;
+ CODE:
+ plperl_spi_cursor_close(cursor);
+
+
BOOT:
items = 0; /* avoid 'unused variable' warning */
diff -rcN plperl.cvs/expected/plperl.out plperl.0/expected/plperl.out
*** plperl.cvs/expected/plperl.out Tue Nov 22 11:48:57 2005
--- plperl.0/expected/plperl.outThu Dec 8 10:35:57 2005
***
*** 367,372
--- 367,386
2
(2 rows)
+ --
+ -- Test spi_fetchrow abort
+ --
+ CREATE OR REPLACE FUNCTION perl_spi_func2() RETURNS INTEGER AS $$
+ my $x = spi_query("select 1 as a union select 2 as a");
+ spi_cursor_close( $x);
+ return 0;
+ $$ LANGUAGE plperl;
+ SELECT * from perl_spi_func2();
+ perl_spi_func2
+
+ 0
+ (1 row)
+
---
--- Test recursion via SPI
---
***
*** 419,422
--- 433,470
---
{{"a\"b",NULL,"c,d"},{"e\\f",NULL,g}}
(1 row)
+
+ --
+ -- Test spi_prepare/spi_exec_prepared/spi_freeplan
+ --
+ CREATE OR REPLACE FUNCTION perl_spi_prepared(INTEGER) RETURNS INTEGER AS $$
+my $x = spi_prepare('select $1 AS a', 'INT4');
+my $q = spi_exec_prepared( $x, $_[0] + 1);
+spi_freeplan($x);
+ return $q->{rows}->[0]->{a};
+ $$ LANGUAGE plperl;
+ SELECT * from perl_spi_prepared(42);
+ perl_spi_prepared
+ ---
+ 43
+ (1 row)
+
+ --
+ -- Test spi_prepare/spi_query_prepared/spi_freeplan
+ --
+ CREATE OR REPLACE FUNCTION perl_spi_prepared_set(INTEGER, INTEGER) RETURNS
SETOF INTEGER AS $$
+ my $x = spi_prepare('SELECT $1 AS a union select $2 as a', 'INT4', 'INT4');
+ my $q = spi_query_prepared( $x, 1+$_[0], 2+$_[1]);
+ while (defined (my $y = spi_fetchrow($q))) {
+ return_next $y->{a};
+ }
+ spi_freeplan($x);
+ return;
+ $$ LANGUAGE plperl;
+ SELECT * from perl_spi_prepared_set(1,2);
+ perl_spi_prepared_set
+ ---
+ 2
+ 4
+ (2 rows)
diff -rcN plperl.cvs/plperl.c plperl.0/plperl.c
*** plperl.cvs/plperl.c Thu Dec 1 13:49:22 2005
--- plperl.0/plperl.c Thu Dec 8 10:51:31 2005
***
*** 55,60 **
Re: [PATCHES] implement prepared queries in plperl
Dmitry, please supply documentation (i.e. a patch to the SGML) to accompany this patch, or at the very least a description of how it works, with the promise of proper documentation to follow. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] TODO-Item: Rename of constraints
On Wed, Dec 07, 2005 at 09:54:44PM +, Simon Riggs wrote: > On Mon, 2005-12-05 at 10:24 +0100, Joachim Wieland wrote: > > o %Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME > > o Have ALTER INDEX update the name of a constraint using that index > > o Add ALTER TABLE RENAME CONSTRAINT, update index name also > My compiler complains: > pg_constraint.c: In function ???RenameConstraint???: > pg_constraint.c:726: warning: ISO C90 forbids mixed declarations and > code Sorry, that's some leftover from code rearrangements. I attach a new version of the patch, this time in the requested context-diff format which I forgot to create the other day. > This probably allows you to rename an inherited constraint to another > name. Not sure if that is a problem, but it probably ought to throw an > error, but I'm not sure who would care. I thought about that but since the constraint gets copied anyway and you have two (more or less) independent constraints afterwards I didn't see a reason why it should be forbidden to rename it. One could throw a warning at least but I don't remember many cases where postgresql issues a warning saying: "hey, what you're doing might be bad but I'll do it anyway". If the consensus on this one however is to forbid it or issue a warning at least, it would be no problem to detect this situation once your inherited constraint patch is in. > I'll test some more to see if my work on inherited constraints conflicts > in any way. Ok, thanks. Joachim diff -cr cvs/pgsql/doc/src/sgml/ddl.sgml cvs.build/pgsql/doc/src/sgml/ddl.sgml *** cvs/pgsql/doc/src/sgml/ddl.sgml 2005-11-20 13:42:45.0 +0100 --- cvs.build/pgsql/doc/src/sgml/ddl.sgml 2005-12-08 13:37:19.0 +0100 *** *** 543,548 --- 543,552 price numeric ); +Since PostgreSQL implements a UNIQUE constraint by +means of an index, the above command will also create an index with the same +name as the constraint. If you later on change the name of one of those, the +name of the corresponding object will be changed automatically as well. diff -cr cvs/pgsql/doc/src/sgml/ref/alter_index.sgml cvs.build/pgsql/doc/src/sgml/ref/alter_index.sgml *** cvs/pgsql/doc/src/sgml/ref/alter_index.sgml 2005-08-28 23:04:33.0 +0200 --- cvs.build/pgsql/doc/src/sgml/ref/alter_index.sgml 2005-12-08 13:37:19.0 +0100 *** *** 108,113 --- 108,122 + Indexes are also used internally by constraints, namely by UNIQUE and + PRIMARY KEY constraints. If you rename an index that is used internally by + a constraint of that type, this constraint will implicitly be renamed as + well. On the other hand, if you rename such a constraint, it will + implicitly rename its corresponding index such that both objects always + have the same name. + + + There was formerly an ALTER INDEX OWNER variant, but this is now ignored (with a warning). An index cannot have an owner different from its table's owner. Changing the table's owner diff -cr cvs/pgsql/doc/src/sgml/ref/alter_table.sgml cvs.build/pgsql/doc/src/sgml/ref/alter_table.sgml *** cvs/pgsql/doc/src/sgml/ref/alter_table.sgml 2005-12-05 15:53:37.0 +0100 --- cvs.build/pgsql/doc/src/sgml/ref/alter_table.sgml 2005-12-08 13:37:19.0 +0100 *** *** 24,29 --- 24,31 action [, ... ] ALTER TABLE [ ONLY ] name [ * ] RENAME [ COLUMN ] column TO new_column + ALTER TABLE [ ONLY ] name [ * ] + ALTER CONSTRAINT constraint_name RENAME TO new_constraint_name ALTER TABLE name RENAME TO new_name ALTER TABLE name *** *** 170,175 --- 172,189 + ALTER CONSTRAINT constraint_name RENAME TO new_constraint_name + + + This form renames a constraint that is defined on the table. Note that if + a constraint is using an index internally (UNIQUE or + PRIMARY KEY constraints), the corresponding index will be + renamed as well. + + + + + ADD table_constraint diff -cr cvs/pgsql/src/backend/catalog/pg_constraint.c cvs.build/pgsql/src/backend/catalog/pg_constraint.c *** cvs/pgsql/src/backend/catalog/pg_constraint.c 2005-12-01 22:38:13.0 +0100 --- cvs.build/pgsql/src/backend/catalog/pg_constraint.c 2005-12-08 13:37:19.0 +0100 *** *** 664,666 --- 664,854 heap_close(conRel, RowExclusiveLock); } + + + /* + * RenameConstraint + *Rename a single constraint record + *conId: The OID of the constraint to rename + *newName: The new name of the constraint + *implicitRename: is this an implicit rename? If so, we will issue + *a notice about the implicit rename + *cmdName: the command that triggered the rename for the "
Re: [PATCHES] implement prepared queries in plperl
> Dmitry, > > please supply documentation (i.e. a patch to the SGML) to accompany this > patch, or at the very least a description of how it works, with the > promise of proper documentation to follow. I am willing to write a proper documentation, but I haven't found the place where to add descriptions for the new functions, and neither the SGML document you're referring to, but I can submit a patch to it if you tell me where it is. If you take this as a promise of proper documentation, I'll explain in short how it works here: I added the following functions: * spi_prepare( $QUERY, @ARGUMENT_TYPES) : $PREPARED_QUERY - prepares a query with typed parameters, returns a prepared query token. * spi_exec_prepared( $PREPARED_QUERY, [%ATTRIBUTES], @ARGUMENTS) : $RESULT - executes a prepared query, returns the result in the same format as spi_exec_query() does. %ATTRIBUTES currently recognizes the only integer 'limit', which is the same as limit in spi_exec_query(). * spi_query_prepared( $PREPARED_QUERY, @ARGUMENTS) : $CURSOR - same as spi_query(), but instead of a text query statement, expects a result of spi_prepare() as the first parameter. * spi_freeplan( $PREPARED_QUERY) - frees the prepared query, must be called explicitly. * spi_cursor_close($CURSOR) - a wrapper around SPI_cursor_close(), to cancel a query session early, which would normally be freed after the last spi_fetchrow() is called. $CURSOR is returned either by spi_query() or spi_query_prepared(). There are also the following fixes to the existing code: - A fix to memory leaks in spi_fetchrow(), by replacing newSV(0) that is intended to signal an error but was never freed, to PL_sv_undef that is safe to return as a non-mortal scalar. - Replace (pointer_type*) SvIV(pointer) to INT2PTR( pointer_type*, SvUV(pointer)), to extinguish warnings. - Changed logic in plperl_spi_query() which I don't think correctly handled the case when SPI_prepare() fails. -- Sincerely, Dmitry Karasik --- catpipe Systems ApS *BSD solutions, consulting, development www.catpipe.net +45 7021 0050 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] implement prepared queries in plperl
Dmitry Karasik wrote: Dmitry, please supply documentation (i.e. a patch to the SGML) to accompany this patch, or at the very least a description of how it works, with the promise of proper documentation to follow. I am willing to write a proper documentation, but I haven't found the place where to add descriptions for the new functions, and neither the SGML document you're referring to, but I can submit a patch to it if you tell me where it is. You should probably be working from a CVS checkout, on which case the file you would need to edit is doc/src/sgml/plperl.sgml You might find the following references useful if you haven't read them already: http://www.postgresql.org/developer/sourcecode and http://www.postgresql.org/docs/faqs.FAQ_DEV.html If you take this as a promise of proper documentation, I'll explain in short how it works here: I will look this over in the next few weeks. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] problem in MS-VC6 environment.
Patch applied to CVS HEAD and 8.1.X. Thanks.
I used WIN32_CLIENT_ONLY rather than _MSC_VER because that covers both
MSC and Borland C. Updated patch attached.
---
Hiroshi Saito wrote:
> Hi Dave-san and Bruce-san.
>
> I have the problem, when building by MS-VC6.
> An error occurs in the 8.1.0 present source codes.
>
> nmake -f win32.mak
> ..\..\port\getaddrinfo.c(244) : error C2065: 'WSA_NOT_ENOUGH_MEMORY'
> ..\..\port\getaddrinfo.c(342) : error C2065: 'WSATYPE_NOT_FOUND'
>
> This is used by winsock2.h. However, Construction of a windows base is
> winsock.h.
> Then, Since MinGW has special environment, this is right. but, it is not
> found in VC6.
> Furthermore, in getaddrinfo.c, IPV6-API is used by LoadLibraryA("ws2_32");
> Referring to of dll the external memory generates this violation by VC6
> specification.
>
> I considered whether the whole should have been converted into winsock2.
> However, Now, DLL of MinGW creation operates wonderfully as it is.
> That's right, it has pliability by replacement of simple DLL.
> Then, I propose the system using winsock(non IPV6) in construction of VC6.
>
> By this patch, the construction by VC6 finished obediently.
>
> I may have some misapprehensions.Therefore, your suggestion is desired.
> Thank you in advance for your understanding.
>
> Regards,
> Hiroshi Saito
>
[ Attachment, skipping... ]
>
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faq
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/pg_config/win32.mak
===
RCS file: /cvsroot/pgsql/src/bin/pg_config/win32.mak,v
retrieving revision 1.3
diff -c -c -r1.3 win32.mak
*** src/bin/pg_config/win32.mak 27 Sep 2005 17:39:33 - 1.3
--- src/bin/pg_config/win32.mak 8 Dec 2005 17:47:49 -
***
*** 55,61
LINK32=link.exe
LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
! advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib\
odbccp32.lib wsock32.lib /nologo /subsystem:console /incremental:no\
/pdb:"$(OUTDIR)\pg_config.pdb" /machine:I386 $(LOPT)
/out:"$(OUTDIR)\pg_config.exe"
LINK32_OBJS= \
--- 55,61
LINK32=link.exe
LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
! advapi32.lib shell32.lib shfolder.lib ole32.lib oleaut32.lib uuid.lib
odbc32.lib\
odbccp32.lib wsock32.lib /nologo /subsystem:console /incremental:no\
/pdb:"$(OUTDIR)\pg_config.pdb" /machine:I386 $(LOPT)
/out:"$(OUTDIR)\pg_config.exe"
LINK32_OBJS= \
Index: src/include/getaddrinfo.h
===
RCS file: /cvsroot/pgsql/src/include/getaddrinfo.h,v
retrieving revision 1.17
diff -c -c -r1.17 getaddrinfo.h
*** src/include/getaddrinfo.h 15 Oct 2005 02:49:41 - 1.17
--- src/include/getaddrinfo.h 8 Dec 2005 17:47:49 -
***
*** 42,47
--- 42,51
#define EAI_MEMORY(-10)
#define EAI_SYSTEM(-11)
#else /* WIN32 */
+ #if defined(WIN32_CLIENT_ONLY)
+ #define WSA_NOT_ENOUGH_MEMORY (WSAENOBUFS)
+ #define WSATYPE_NOT_FOUND (WSABASEERR+109)
+ #endif
#define EAI_AGAIN WSATRY_AGAIN
#define EAI_BADFLAGS WSAEINVAL
#define EAI_FAIL WSANO_RECOVERY
Index: src/port/getaddrinfo.c
===
RCS file: /cvsroot/pgsql/src/port/getaddrinfo.c,v
retrieving revision 1.21
diff -c -c -r1.21 getaddrinfo.c
*** src/port/getaddrinfo.c 15 Oct 2005 02:49:51 - 1.21
--- src/port/getaddrinfo.c 8 Dec 2005 17:47:50 -
***
*** 40,45
--- 40,46
#include
+ #if !defined(WIN32_CLIENT_ONLY)
/*
* The native routines may or may not exist on the Windows platform we are on,
* so we dynamically look up the routines, and call them via function
pointers.
***
*** 129,134
--- 130,136
return (getaddrinfo_ptr != NULL);
}
#endif
+ #endif
/*
***
*** 149,155
*psin;
struct addrinfo hints;
! #ifdef WIN32
/*
* If Windows has native IPv6 support, use the native Windows routine.
--- 151,157
*psin;
struct addrinfo hints;
! #if defined(WIN32) && !defined(WIN32_CLIENT_ONLY)
/*
* If Windows has native IPv6 support, use the native Windows routine.
***
*** 272,278
{
if (res)
{
Re: [PATCHES] [DOCS] pl/pgSQL doco patch
Add documentation about the inability of plpsql to use parameter names that are the same as column names used in the function. I moved the item up on the list of porting issues. Patch applied to CVS HEAD and 8.1.X. Thanks. --- Philip Yarra wrote: > Hi, I supplied a minor doco patch relating to porting pl/SQL to pl/pgSQL: > http://archives.postgresql.org/pgsql-hackers/2005-10/msg01295.php. Also > attached here. > > Could someone please review and apply this for me? > > Regards, Philip. > > -- > > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." - Brian W. Kernighan > > - > Utiba Pty Ltd > This message has been scanned for viruses and > dangerous content by Utiba mail server and is > believed to be clean. > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [PATCHES] pl/pgSQL doco patch
I think the Oracle porting section is the correct place for this item. Thanks for the patch. --- Philip Yarra wrote: > On Thu, 17 Nov 2005 01:40 am, Andrew Dunstan wrote: > > I am wondering we should make this warning more prominent - it would be > > easily missed buried on the Oracle porting section, and I have seen > > people caught by it lots of times. > > I added it to the Oracle section because I found this syntax while porting an > Oracle stored proc to a pl/pgSQL function, and assumed it was an Oracle-ism. > > Do other RDBMSs also allow you to qualify function_name.param_name to > distinguish a param from a column of the same name? If so, sure, I'll put it > somewhere more general (suggestions?), and Tom, I think that would lend > weight to allowing PostgreSQL to do it too (not because it's The Right Thing, > but for interoperability and ease of porting). Thoughts? > > Regards, Philip. > > -- > > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." - Brian W. Kernighan > > - > Utiba Pty Ltd > This message has been scanned for viruses and > dangerous content by Utiba mail server and is > believed to be clean. > > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] psql, tab completion additions
Patch applied to CVS HEAD only. Thanks. --- Sergey E. Koposov wrote: > > Now the patch have been made using "cvs diff -c" > > Sergey > > On Tue, 29 Nov 2005, Sergey E. Koposov wrote: > > > Hello All, > > > > 1) I'm proposing a patch to do the DROP FUNCTION argument tab completion. > > Now, the arguments of the drop function can be tab completed. for example > > > > drop function strpos ( > > > > drop FUNCTION strpos (text, text) > > > > or: > > > > wsdb=# drop FUNCTION length ( > > bit)bytea) character) lseg) path) text) > > > > wsdb# DROP FUNCTION length ( character) > > > > I think that this patch should be rather useful. At it least I hate > > always to type all the arguments of the dropped functions. > > > > 2) Also some fixes applied for the > > CREATE INDEX syntax > > > > now the parenthesises are inserted by tab pressing. > > suppose I have the table q3c: > > wsdb=# \d q3c > > Table "public.q3c" > > Column | Type | Modifiers > > +--+--- > > ipix | bigint | > > ra | double precision | > > dec| double precision | > > > > Now if I do > > wsdb# create index xxx on q3c > > > > wsdb# CREATE INDEX xxx on q3c ( > > > > wsdb=# CREATE INDEX xxx on q3c ( > > "dec" ipix ra > > > > wsdb=# CREATE INDEX xxx on q3c ( ra > > > > Regards, > > Sergey > > > > * > > Sergey E. Koposov > > Max-Planck Institut for Astronomy > > Web: http://lnfm1.sai.msu.ru/~math > > E-mail: [EMAIL PROTECTED] > > > > > > * > Sergey E. Koposov > Max-Planck Institut for Astronomy > Web: http://lnfm1.sai.msu.ru/~math > E-mail: [EMAIL PROTECTED] > Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Trivial doc-patch for constraint description
Patch applied to CVS HEAD and 8.1.X. Thanks. --- Joachim Wieland wrote: > Hi, > > there's a paragraph in the ALTER TABLE reference page that reads: > > DROP CONSTRAINT > > This form drops constraints on a table. Currently, constraints on tables > are not required to have unique names, so there may be more than one > constraint matching the specified name. All matching constraints will be > dropped. > > To my knowledge, it is no longer possible to create constraints with the > same name for the same relation. When you create a constraint and specify > the same name explictly, an error is raised. Implicit constraint creation > won't choose an existing name either and up to now you could not rename a > constraint. Renaming works with the patch I sent in a few hours ago but this > patch as well won't allow constraints with identical names on the same > relation. > > The attached patch thus removes the note in the docs. > > > Joachim [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] AIX FAQ update
Patch applied to CVS HEAD and 8.1.X. Thanks. --- Seneca Cunningham wrote: > FAQ_AIX in 8.1.0 contains outdated information about how to deal with > postgres problems due to readline. The attached patch replaces that > section of it with better ways of handling the problem. > > -- > Seneca Cunningham > [EMAIL PROTECTED] > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] initdb detecting date order
Here's a patch for initdb detecting the date order of the lc_time locale
and initializing the datestyle parameter of the new cluster
accordingly.
This relies on feeding an umambiguous date through strftime("%x") and
checking in which order things come out. (This was suggested to me by
Martin Pitt a while ago.) I've tested this with a number of locales
and it seems to work. Does anyone see a problem with this?
(Documentation and perhaps an initdb progress notification line is of
course still missing.)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur ../../../../cvs-pgsql/src/bin/initdb/initdb.c ./initdb.c
--- ../../../../cvs-pgsql/src/bin/initdb/initdb.c 2005-12-03 22:30:51.0 +0100
+++ ./initdb.c 2005-12-09 02:28:41.0 +0100
@@ -57,11 +57,13 @@
#ifdef HAVE_LANGINFO_H
#include
#endif
+#include
#include "libpq/pqsignal.h"
#include "mb/pg_wchar.h"
#include "getaddrinfo.h"
#include "getopt_long.h"
+#include "miscadmin.h"
#ifndef HAVE_INT_OPTRESET
int optreset;
@@ -186,6 +188,7 @@
static void trapsig(int signum);
static void check_ok(void);
static char *escape_quotes(const char *src);
+static int locale_date_order(const char *locale);
static bool chklocale(const char *locale);
static void setlocales(void);
static void usage(const char *progname);
@@ -1195,6 +1198,20 @@
snprintf(repltok, sizeof(repltok), "lc_time = '%s'", lc_time);
conflines = replace_token(conflines, "#lc_time = 'C'", repltok);
+ switch (locale_date_order(lc_time)) {
+ case DATEORDER_YMD:
+ strcpy(repltok, "datestyle = 'iso, ymd'");
+ break;
+ case DATEORDER_DMY:
+ strcpy(repltok, "datestyle = 'iso, dmy'");
+ break;
+ case DATEORDER_MDY:
+ default:
+ strcpy(repltok, "datestyle = 'iso, mdy'");
+ break;
+ }
+ conflines = replace_token(conflines, "#datestyle = 'iso, mdy'", repltok);
+
snprintf(path, sizeof(path), "%s/postgresql.conf", pg_data);
writefile(path, conflines);
@@ -2053,6 +2070,51 @@
}
/*
+ * Determine likely date order from locale
+ */
+static int
+locale_date_order(const char *locale)
+{
+ struct tm testtime;
+ char buf[128];
+ char *posD;
+ char *posM;
+ char *posY;
+ char *save;
+ size_t res;
+
+ save = setlocale(LC_TIME, NULL);
+ if (!save)
+ return DATEORDER_MDY;
+ save = xstrdup(save);
+
+ setlocale(LC_TIME, locale);
+
+ memset(&testtime, 0, sizeof(testtime));
+ testtime.tm_mday = 22;
+ testtime.tm_mon = 10; /* November, should come out as "11" */
+ testtime.tm_year = 133; /* 2033 */
+
+ res = strftime(buf, sizeof(buf), "%x", &testtime);
+
+ setlocale(LC_TIME, save);
+ free(save);
+
+ if (res == 0)
+ return DATEORDER_MDY;
+
+ posM = strstr(buf, "11");
+ posD = strstr(buf, "22");
+ posY = strstr(buf, "33");
+
+ if (posY < posD && posY < posM)
+ return DATEORDER_YMD;
+ if (posD < posM)
+ return DATEORDER_DMY;
+ return DATEORDER_MDY;
+}
+
+/*
* check if given string is a valid locale specifier
*/
static bool
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] initdb detecting date order
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Here's a patch for initdb detecting the date order of the lc_time locale > and initializing the datestyle parameter of the new cluster > accordingly. Er, is that really a good idea? It will make it impossible to document what the "default" behavior is; among other things, this will probably break installcheck regression tests. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] initdb detecting date order
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Here's a patch for initdb detecting the date order of the lc_time locale > > and initializing the datestyle parameter of the new cluster > > accordingly. > > Er, is that really a good idea? It will make it impossible to document > what the "default" behavior is; among other things, this will probably > break installcheck regression tests. FYI, it is a TODO item, with a question mark: * Have initdb set the input DateStyle (MDY or DMY) based on locale? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] initdb detecting date order
Tom Lane wrote: > Er, is that really a good idea? It will make it impossible to > document what the "default" behavior is; I think a localized default behavior is more important than a fixed default behavior for everyone. We already adjust the locales and encodings in initdb and this is just a natural extension of that theme. No robust application will rely on the default setting anyway; if you want to be sure you have to set it or at least query it anyway. > among other things, this > will probably break installcheck regression tests. The regression tests are not affected by this (which may itself be an issue of concern). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] initdb detecting date order
Peter Eisentraut wrote: > Tom Lane wrote: > > Er, is that really a good idea? It will make it impossible to > > document what the "default" behavior is; > > I think a localized default behavior is more important than a fixed > default behavior for everyone. We already adjust the locales and > encodings in initdb and this is just a natural extension of that theme. > No robust application will rely on the default setting anyway; if you > want to be sure you have to set it or at least query it anyway. Agreed. It seems like a logical extension to what we already do. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] initdb detecting date order
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I think a localized default behavior is more important than a fixed > default behavior for everyone. We already adjust the locales and > encodings in initdb and this is just a natural extension of that theme. So --no-locale would suppress any change? OK, I can live with it. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] CVS of 8.1.x MS-VC6 probrem.
Dear Bruce san. I reconfirmed MS-VC6. Thank you for wonderful correspondence. However, Another problem newly occurred. This solves the problem of snprintf and vsnprintf. Please apply it. Thank you. Regards, Hiroshi Saito--- src/include/pg_config.h.win32.orig Fri Dec 9 13:30:41 2005 +++ src/include/pg_config.h.win32 Fri Dec 9 13:32:46 2005 @@ -23,6 +23,12 @@ #define HAVE_RANDOM #endif +/* use _snprintf and _vsnprintf */ +#define HAVE_DECL_SNPRINTF 1 +#define snprintf_snprintf +#define HAVE_DECL_VSNPRINTF 1 +#define vsnprintf _vsnprintf + /* defines for dynamic linking on Win32 platform */ #ifdef __CYGWIN__ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] CVS of 8.1.x MS-VC6 probrem.
That code was removed when *printf was fixed, and we thought it wasn't needed anumore. Thanks for the quick report. Patch applied to CVS HEAD and 8.1.X. --- Hiroshi Saito wrote: > Dear Bruce san. > > I reconfirmed MS-VC6. Thank you for wonderful correspondence. > However, Another problem newly occurred. > This solves the problem of snprintf and vsnprintf. > Please apply it. > > Thank you. > > Regards, > Hiroshi Saito [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] CVS of 8.1.x MS-VC6 probrem.
While I have applied your patch, I am now confused about something. Your change was to pg_config.h.win32, which is used only for WIN32_CLIENT_ONLY compiles, namely MSVC and Borland C. The addition was: /* use _snprintf and _vsnprintf */ #define HAVE_DECL_SNPRINTF 1 #define snprintf_snprintf #define HAVE_DECL_VSNPRINTF 1 #define vsnprintf _vsnprintf Now, I think the problem is that with those defines, we will not use our port/snprintf.c, meaning the %$ escapes for language translation will not work for those builds. I realize the backend is the most important for messages, but libpq and psql also have message translation. Would you try removing those lines you added and add these to pg_config.h.win32: #define HAVE_DECL_SNPRINTF 1 #define HAVE_DECL_VSNPRINTF 1 #define HAVE_SNPRINTF 1 #define HAVE_VSNPRINTF 1 #define USE_REPL_SNPRINTF 1 Does that allow it to compile? We have limited time before 8.1.1 is packaged. --- pgman wrote: > > That code was removed when *printf was fixed, and we thought it wasn't > needed anumore. Thanks for the quick report. > > Patch applied to CVS HEAD and 8.1.X. > > --- > > > Hiroshi Saito wrote: > > Dear Bruce san. > > > > I reconfirmed MS-VC6. Thank you for wonderful correspondence. > > However, Another problem newly occurred. > > This solves the problem of snprintf and vsnprintf. > > Please apply it. > > > > Thank you. > > > > Regards, > > Hiroshi Saito > > [ Attachment, skipping... ] > > > > > ---(end of broadcast)--- > > TIP 4: Have you searched our list archives? > > > >http://archives.postgresql.org > > -- > Bruce Momjian| http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] CVS of 8.1.x MS-VC6 probrem.
Also, if my suggested changes do not allow it to compile, please show us the compile error message with my suggested changes. Thanks. --- Bruce Momjian wrote: > > While I have applied your patch, I am now confused about something. Your > change was to pg_config.h.win32, which is used only for > WIN32_CLIENT_ONLY compiles, namely MSVC and Borland C. > > The addition was: > > /* use _snprintf and _vsnprintf */ > #define HAVE_DECL_SNPRINTF 1 > #define snprintf_snprintf > #define HAVE_DECL_VSNPRINTF 1 > #define vsnprintf _vsnprintf > > Now, I think the problem is that with those defines, we will not use our > port/snprintf.c, meaning the %$ escapes for language translation will > not work for those builds. I realize the backend is the most important > for messages, but libpq and psql also have message translation. > > Would you try removing those lines you added and add these to > pg_config.h.win32: > > #define HAVE_DECL_SNPRINTF 1 > #define HAVE_DECL_VSNPRINTF 1 > #define HAVE_SNPRINTF 1 > #define HAVE_VSNPRINTF 1 > #define USE_REPL_SNPRINTF 1 > > Does that allow it to compile? We have limited time before 8.1.1 is > packaged. > > --- > > pgman wrote: > > > > That code was removed when *printf was fixed, and we thought it wasn't > > needed anumore. Thanks for the quick report. > > > > Patch applied to CVS HEAD and 8.1.X. > > > > --- > > > > > > Hiroshi Saito wrote: > > > Dear Bruce san. > > > > > > I reconfirmed MS-VC6. Thank you for wonderful correspondence. > > > However, Another problem newly occurred. > > > This solves the problem of snprintf and vsnprintf. > > > Please apply it. > > > > > > Thank you. > > > > > > Regards, > > > Hiroshi Saito > > > > [ Attachment, skipping... ] > > > > > > > > ---(end of broadcast)--- > > > TIP 4: Have you searched our list archives? > > > > > >http://archives.postgresql.org > > > > -- > > Bruce Momjian| http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > -- > Bruce Momjian| http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] CVS of 8.1.x MS-VC6 probrem.
Dear Bruce-san. > > #define HAVE_DECL_SNPRINTF 1 > > #define HAVE_DECL_VSNPRINTF 1 > > #define HAVE_SNPRINTF 1 > > #define HAVE_VSNPRINTF 1 > > #define USE_REPL_SNPRINTF 1 Ummm... This causes injustice. -- libpq.lib(fe-connect.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_snprintf" は未解決です libpq.lib(getaddrinfo.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_snprintf" は未解決で す libpq.lib(fe-auth.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_snprintf" は未解決です libpq.lib(win32.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_sprintf" は未解決です libpq.lib(fe-connect.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_sprintf" は未解決です libpq.lib(fe-exec.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_sprintf" は未解決です libpq.lib(fe-print.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_sprintf" は未解決です libpq.lib(fe-protocol2.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_sprintf" は未解決で す libpq.lib(encnames.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_fprintf" は未解決です libpq.lib(fe-auth.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_fprintf" は未解決です libpq.lib(fe-connect.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_fprintf" は未解決です libpq.lib(fe-exec.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_fprintf" は未解決です libpq.lib(fe-print.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_fprintf" は未解決です libpq.lib(fe-misc.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_fprintf" は未解決です libpq.lib(fe-exec.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_vsnprintf" は未解決です libpq.lib(pqexpbuffer.obj) : error LNK2001: 外部ｼﾝﾎﾞﾙ "_pg_vsnprintf" は未解決で す .\Release\libpq.dll : fatal error LNK1120: 外部参照 4 が未解決です。 NMAKE : fatal error U1077: 'link.exe' : ﾘﾀｰﾝ ｺｰﾄﾞ '0x460' ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] unsubscribe
unsubscribe
Re: [PATCHES] CVS of 8.1.x MS-VC6 probrem.
> for messages, but libpq and psql also have message translation. The work of using port/snprintf is needed. and If gettext is used Is it desired now? It will be tonight if it becomes so. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
