Re: [PATCHES] [pgsql-hackers-win32] Re : Win32 binaries test / pg_dump problem
Bruce Momjian wrote: + #ifndef WIN32 + #define R_TEXTFILEr + #else + #define R_TEXTFILErb + #endif This appears to be redundant with #if defined(__CYGWIN__) || defined(WIN32) #define PG_BINARY O_BINARY #define PG_BINARY_R rb #define PG_BINARY_W wb #else #define PG_BINARY 0 #define PG_BINARY_R r #define PG_BINARY_W w #endif in c.h. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] OWNER TO mega patch #2
Already applied by Tom. --- Christopher Kings-Lynne wrote: Hi, This is the final patch that adds OWNER TO commands to every object. This includes tablespaces. I have also added RENAME TO on tablespaces. Full docs changes are included (+ 3 new files that must be put in doc/src/sgml/ref). All new regression tests included also. Please review and apply this soon so that I can fix pg_dump to use these new commands before the 30th :) Cheers, Chris [ application/x-gzip is not supported, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 7: don't forget to increase your free space map settings
Re: [PATCHES] [pgsql-hackers-win32] Re : Win32 binaries test / pg_dump
OK, thanks, adjusted, and I added a comment about control-z handling. --- Peter Eisentraut wrote: Bruce Momjian wrote: + #ifndef WIN32 + #define R_TEXTFILEr + #else + #define R_TEXTFILErb + #endif This appears to be redundant with #if defined(__CYGWIN__) || defined(WIN32) #define PG_BINARY O_BINARY #define PG_BINARY_R rb #define PG_BINARY_W wb #else #define PG_BINARY 0 #define PG_BINARY_R r #define PG_BINARY_W w #endif in c.h. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [pgsql-hackers-win32] Data directory with trailing [back]slash
I am now confused about the original report. I don't see how my fix would correct the reported problem. trim_trailing_separator() would have handled d:\pgdata\ and d:\pgdata just fine. The fix only corrects d:\. Magnus, does current CVS fix the problem? --- Andrew Dunstan wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: It's not possible to start the postmaster on win32 with: postmaster -D d:\pgdata\ or postmaster -D d:/pgdata/ Sounds like canonicalize_path() needs to be applied a bit sooner than it is. BTW I think canonicalize_path() is a few bricks shy of a load yet: I'm not sure it works well with Windows drive-letters, and it definitely will strip significant slashes when given input like '/' or 'C:\'. Feel free to fix those problems while at it... Or use the attached patch, which I think does it right. cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [PATCHES] [pgsql-hackers-win32] Data directory with trailing [back]slash
I think this still is not fixed. I think we need to add a call to trim_trailing_separator() in checkDataDir(). Magnus, can you confirm this will fix it? --- Bruce Momjian wrote: I am now confused about the original report. I don't see how my fix would correct the reported problem. trim_trailing_separator() would have handled d:\pgdata\ and d:\pgdata just fine. The fix only corrects d:\. Magnus, does current CVS fix the problem? --- Andrew Dunstan wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: It's not possible to start the postmaster on win32 with: postmaster -D d:\pgdata\ or postmaster -D d:/pgdata/ Sounds like canonicalize_path() needs to be applied a bit sooner than it is. BTW I think canonicalize_path() is a few bricks shy of a load yet: I'm not sure it works well with Windows drive-letters, and it definitely will strip significant slashes when given input like '/' or 'C:\'. Feel free to fix those problems while at it... Or use the attached patch, which I think does it right. cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: 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
[PATCHES]
subscribe end
Re: [PATCHES] [pgsql-hackers-win32] Data directory with trailing [back]slash
Oops, path patch attached.
---
Bruce Momjian wrote:
I think this still is not fixed. I think we need to add a call to
trim_trailing_separator() in checkDataDir(). Magnus, can you confirm
this will fix it?
---
Bruce Momjian wrote:
I am now confused about the original report. I don't see how my fix
would correct the reported problem. trim_trailing_separator() would
have handled d:\pgdata\ and d:\pgdata just fine. The fix only corrects
d:\.
Magnus, does current CVS fix the problem?
---
Andrew Dunstan wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
It's not possible to start the postmaster on win32 with:
postmaster -D d:\pgdata\
or
postmaster -D d:/pgdata/
Sounds like canonicalize_path() needs to be applied a bit sooner than
it is.
BTW I think canonicalize_path() is a few bricks shy of a load yet:
I'm not sure it works well with Windows drive-letters, and it definitely
will strip significant slashes when given input like '/' or 'C:\'.
Feel free to fix those problems while at it...
Or use the attached patch, which I think does it right.
cheers
andrew
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (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: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (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: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/postmaster/postmaster.c
===
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.407
diff -c -c -r1.407 postmaster.c
*** src/backend/postmaster/postmaster.c 11 Jul 2004 00:18:43 - 1.407
--- src/backend/postmaster/postmaster.c 11 Jul 2004 21:29:16 -
***
*** 372,378
InitializeGUCOptions();
userPGDATA = getenv(PGDATA); /* default value */
!
opterr = 1;
while ((opt = getopt(argc, argv, A:a:B:b:c:D:d:Fh:ik:lm:MN:no:p:Ss-:)) != -1)
--- 372,379
InitializeGUCOptions();
userPGDATA = getenv(PGDATA); /* default value */
! canonicalize_path(userPGDATA);
!
opterr = 1;
while ((opt = getopt(argc, argv, A:a:B:b:c:D:d:Fh:ik:lm:MN:no:p:Ss-:)) != -1)
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.214
diff -c -c -r1.214 guc.c
*** src/backend/utils/misc/guc.c11 Jul 2004 00:18:44 - 1.214
--- src/backend/utils/misc/guc.c11 Jul 2004 21:29:19 -
***
*** 113,118
--- 113,119
static bool assign_stage_log_stats(bool newval, bool doit, GucSource source);
static bool assign_log_stats(bool newval, bool doit, GucSource source);
static bool assign_transaction_read_only(bool newval, bool doit, GucSource source);
+ static const char *assign_canonical_path(const char *newval, bool doit, GucSource
source);
static void ReadConfigFile(char *filename, GucContext context);
***
*** 1470,1476
the specified file.)
},
Dynamic_library_path,
! $libdir, NULL, NULL
},
{
--- 1471,1477
the specified file.)
},
Dynamic_library_path,
! $libdir,
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Attached is an updated ALTER TABLE ... SET TABLESPACE patch. Does this patch allow setting the tablespace of sequences as well? If so, then you will need to modify pg_dump of SERIAL sequences. Perhaps output a ALTER TABLE/SET TABLESPACE command after the CREATE TABLE definition to move the SERIAL sequence. The same argument applies if it allows moving indexes. (Unique and Primary Keys) Sequences no, toast tables no, indexes yes. So we need the latter part of the above-mentioned patch. Anyone? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Applied by Tom. --- Gavin Sherry wrote: Hi all, Attached is an updated ALTER TABLE ... SET TABLESPACE patch. It uses the block by block copy mechanism proposed by Tom and handles i) ALTER TABLE index and ii) Copying of TOAST tables and the TOAST table's index. It doesn't handle copying of system tables (pg_largeobject) and, in the interests of code reuse, the patch fiddles with the code used by CLUSTER. This isn't great but I wanted to get a patch in before 1 July since I think the feature is very important -- even for the first release. Thanks, Gavin Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Example for create function using argument names
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links at the bottom of the developer's page, http://developer.postgresql.org/index.php. --- Gavin Sherry wrote: Small addition. Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Type typo in parameter of pgsql function
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links at the bottom of the developer's page, http://developer.postgresql.org/index.php. --- Michael Glaesemann wrote: Hello all This patch fixes a small error in the Porting PL/SQL to PL/pgSQL section where a instr function parameter is mistyped as varchar. It works properly when changed to integer. This is only my second patch. I generated it using cvs diff -c filename. If I've bungled the format, please let me know. Michael Glaesemann grzm myrealbox com Index: plpgsql.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.39 diff -c -r1.39 plpgsql.sgml *** plpgsql.sgml 4 Jul 2004 02:48:52 - 1.39 --- plpgsql.sgml 5 Jul 2004 01:12:31 - *** *** 2957,2963 $$ LANGUAGE plpgsql; ! CREATE FUNCTION instr(varchar, varchar, varchar) RETURNS integer AS $$ DECLARE string ALIAS FOR $1; string_to_search ALIAS FOR $2; --- 2957,2963 $$ LANGUAGE plpgsql; ! CREATE FUNCTION instr(varchar, varchar, integer) RETURNS integer AS $$ DECLARE string ALIAS FOR $1; string_to_search ALIAS FOR $2; ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Don't 'kill -9' the postmaster
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Bruce Momjian [EMAIL PROTECTED] writes: Added to TODO; * Allow moving sequences and toast tables to other tablespaces in case no one does it. Please remove that; if I thought either one was a good idea, I would have allowed it in the committed patch. Sequences are too small to be worth moving around, and may someday be reimplemented in a fashion that doesn't use up a separate disk file for each one. If we allow SET TABLESPACE on them we will be limiting our future flexibility for no useful gain. Toast tables are bound to their parent tables because (a) pg_dump isn't nearly smart enough to handle moving them, and (b) I've got concerns about how you decide whether a person is authorized to move one. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Attached is an updated ALTER TABLE ... SET TABLESPACE patch. Does this patch allow setting the tablespace of sequences as well? If so, then you will need to modify pg_dump of SERIAL sequences. Perhaps output a ALTER TABLE/SET TABLESPACE command after the CREATE TABLE definition to move the SERIAL sequence. The same argument applies if it allows moving indexes. (Unique and Primary Keys) Sequences no, toast tables no, indexes yes. So we need the latter part of the above-mentioned patch. Anyone? Added to TODO; * Allow moving sequences and toast tables to other tablespaces in case no one does it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
OK, removed. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Added to TODO; * Allow moving sequences and toast tables to other tablespaces in case no one does it. Please remove that; if I thought either one was a good idea, I would have allowed it in the committed patch. Sequences are too small to be worth moving around, and may someday be reimplemented in a fashion that doesn't use up a separate disk file for each one. If we allow SET TABLESPACE on them we will be limiting our future flexibility for no useful gain. Toast tables are bound to their parent tables because (a) pg_dump isn't nearly smart enough to handle moving them, and (b) I've got concerns about how you decide whether a person is authorized to move one. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [PATCHES] actualized czech FAQ again
Thanks. New FAQ version added. --- Pavel Stehule wrote: Hello I reformated FAQ into html. I am sending diff and html file. regards Pavel Stehule Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: 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] plperl fixes
Previous patch removed from the queue.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Andrew Dunstan wrote:
The attached patch, which incorporates the previous one sent and
currently unapplied regarding spi_internal.c, makes some additional
fixes relating to return types, and also contains the fix for
preventing the use of insecure versions of Safe.pm.
There is one remaing return case that does not appear to work, namely
return of a composite directly in a select, i.e. if foo returns some
composite type, 'select * from foo()' works but 'select foo()' doesn't.
We will either fix that or document it as a limitation.
The function plperl_func_handler is a mess - I will try to get it
cleaned up (and split up) in a subsequent patch, time permitting.
Also, reiterating previous advice - this changes slightly the API for
spi_exec_query - the returned object has either 2 or 3 members: 'status'
(string) and 'proceesed' (int,- number of rows) and, if rows are
returned, 'rows' (array of tuple hashes).
cheers
andrew
Index: plperl.c
===
RCS file: /projects/cvsroot/pgsql-server/src/pl/plperl/plperl.c,v
retrieving revision 1.45
diff -c -w -r1.45 plperl.c
*** plperl.c 1 Jul 2004 20:50:22 - 1.45
--- plperl.c 7 Jul 2004 15:35:35 -
***
*** 80,85
--- 80,86
CommandId fn_cmin;
boollanpltrusted;
boolfn_retistuple; /* true, if function returns tuple */
+ boolfn_retisset;/*true, if function returns set*/
Oid ret_oid;/* Oid of returning type */
FmgrInforesult_in_func;
Oid result_typioparam;
***
*** 95,105
* Global data
**/
static int plperl_firstcall = 1;
static PerlInterpreter *plperl_interp = NULL;
static HV *plperl_proc_hash = NULL;
! AV *g_row_keys = NULL;
! AV *g_column_keys = NULL;
! int g_attr_num = 0;
/**
* Forward declarations
--- 96,108
* Global data
**/
static int plperl_firstcall = 1;
+ static bool plperl_safe_init_done = false;
static PerlInterpreter *plperl_interp = NULL;
static HV *plperl_proc_hash = NULL;
! static AV *g_row_keys = NULL;
! static AV *g_column_keys = NULL;
! static SV *srf_perlret=NULL; /*keep returned value*/
! static int g_attr_num = 0;
/**
* Forward declarations
***
*** 215,225
* no commas between the next lines please. They are supposed to be
* one string
*/
! require Safe; SPI::bootstrap(); use vars qw(%_SHARED);
! use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');
!
$PLContainer-permit_only(':default');$PLContainer-permit(':base_math');
! $PLContainer-share(qw[elog spi_exec_query DEBUG LOG INFO
NOTICE WARNING ERROR %SHARED ]);
! sub ::mksafefunc { return $PLContainer-reval(qq[sub { $_[0]
$_[1]}]); }
sub ::mkunsafefunc {return eval(qq[ sub { $_[0] $_[1] } ]); }
};
--- 218,224
* no commas between the next lines please. They are supposed to be
* one string
*/
! SPI::bootstrap(); use vars qw(%_SHARED);
sub ::mkunsafefunc {return eval(qq[ sub { $_[0] $_[1] } ]); }
};
***
*** 238,243
--- 237,277
}
+
+ static void
+ plperl_safe_init(void)
+ {
+ static char *safe_module =
+ require Safe; $Safe::VERSION;
+
+ static char * safe_ok =
+ use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');
+
$PLContainer-permit_only(':default');$PLContainer-permit(':base_math');
+ $PLContainer-share(qw[elog spi_exec_query DEBUG LOG INFO
NOTICE WARNING ERROR %SHARED ]);
+ sub ::mksafefunc { return $PLContainer-reval(qq[sub { $_[0]
$_[1]}]); }
+ ;
+
+ static char * safe_bad =
+ use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');
+
$PLContainer-permit_only(':default');$PLContainer-permit(':base_math');
+ $PLContainer-share(qw[elog DEBUG LOG INFO NOTICE WARNING
ERROR %SHARED ]);
+
Re: [PATCHES] plperl spi_exec_query patch
Patch withdrawn by author.
---
Andrew Dunstan wrote:
The following patch applies a change I inadvertantly left out of the
previous patch, and makes spi_exec_query work correctly in the case of a
select query.
Test shows:
CREATE TABLE test (
i int,
v varchar
);
CREATE TABLE
INSERT INTO test (i, v) VALUES (1,'first line');
INSERT 25616 1
INSERT INTO test (i, v) VALUES (2,'second line');
INSERT 25617 1
INSERT INTO test (i, v) VALUES (3,'third line');
INSERT 25618 1
INSERT INTO test (i, v) VALUES (4,'immortal');
INSERT 25619 1
create function test_munge() returns setof test language plperl as $$
my $res = [];
my $rv = spi_exec_query(select i,v from plperltest.test;);
my $status = $rv-{status};
my $rows = @{$rv-{rows}};
my $processed = $rv-{processed};
foreach my $rn (0..$rows-1)
{
my $row = $rv-{rows}[$rn];
$row-{i} += 200 if defined($row-{i});
$row-{v} =~ tr/A-Za-z/a-zA-Z/ if (defined($row-{v}));
push @$res,$row;
}
return $res;
$$;
CREATE FUNCTION
select * from test_munge();
i | v
-+-
201 | FIRST LINE
202 | SECOND LINE
203 | THIRD LINE
204 | IMMORTAL
(4 rows)
cheers
andrew
!DSPAM:40e84605260381013413849!
[ text/x-patch is unsupported, treating like TEXT/PLAIN ]
Index: spi_internal.c
===
RCS file: /projects/cvsroot/pgsql-server/src/pl/plperl/spi_internal.c,v
retrieving revision 1.1
diff -c -r1.1 spi_internal.c
*** spi_internal.c1 Jul 2004 20:50:22 - 1.1
--- spi_internal.c4 Jul 2004 17:48:41 -
***
*** 82,123
* Get the attributes value
/
attdata = SPI_getvalue(tuple, tupdesc, i+1);
! hv_store(array, attname, strlen(attname), newSVpv(attdata,0), 0);
}
return array;
}
static HV*
! plperl_spi_execute_fetch_result(SPITupleTable *tuptable, int rows, int status)
{
HV *result;
int i;
result = newHV();
if (status == SPI_OK_UTILITY)
{
hv_store(result, status, strlen(status),
newSVpv(SPI_OK_UTILITY,0), 0);
! hv_store(result, rows, strlen(rows), newSViv(rows), 0);
}
else if (status != SPI_OK_SELECT)
{
hv_store(result, status, strlen(status),
newSVpv((char*)plperl_spi_status_string(status),0), 0);
! hv_store(result, rows, strlen(rows), newSViv(rows), 0);
}
else
{
! if (rows)
{
- char* key=palloc(sizeof(int));
HV *row;
! for (i = 0; i rows; i++)
{
row = plperl_hash_from_tuple(tuptable-vals[i],
tuptable-tupdesc);
! sprintf(key, %i, i);
! hv_store(result, key, strlen(key),
newRV_noinc((SV*)row), 0);
}
SPI_freetuptable(tuptable);
}
}
--- 82,129
* Get the attributes value
/
attdata = SPI_getvalue(tuple, tupdesc, i+1);
! if(attdata)
! hv_store(array, attname, strlen(attname), newSVpv(attdata,0),
0);
! else
! hv_store(array, attname, strlen(attname), newSVpv(undef,0),
0);
}
return array;
}
static HV*
! plperl_spi_execute_fetch_result(SPITupleTable *tuptable, int processed, int status)
{
HV *result;
+ AV *rows;
int i;
result = newHV();
+ rows = newAV();
if (status == SPI_OK_UTILITY)
{
hv_store(result, status, strlen(status),
newSVpv(SPI_OK_UTILITY,0), 0);
! hv_store(result, processed, strlen(processed), newSViv(processed),
0);
}
else if (status != SPI_OK_SELECT)
{
hv_store(result, status, strlen(status),
newSVpv((char*)plperl_spi_status_string(status),0), 0);
! hv_store(result, processed, strlen(processed), newSViv(processed),
0);
}
else
{
! hv_store(result, status, strlen(status),
newSVpv((char*)plperl_spi_status_string(status),0), 0);
! hv_store(result, processed, strlen(processed), newSViv(processed),
0);
! if (processed)
{
HV *row;
! for (i = 0; i processed; i++)
{
row = plperl_hash_from_tuple(tuptable-vals[i],
tuptable-tupdesc);
! av_store(rows, i, newRV_noinc((SV*)row));
Re: [PATCHES] value.h has no VALUE_H
Patch applied. Thanks. --- Alvaro Herrera wrote: The outer #define was forgotten. Attached patch adds it; please apply. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Sallah, I said NO camels! That's FIVE camels; can't you count? (Indiana Jones) [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 7: don't forget to increase your free space map settings
Re: [PATCHES] pg_autovacuum integration attempt #2
I have added this patch plus your later comments to the patch queue. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Matthew T. O'Connor wrote: I have make the changes suggested after I posted my last patch, I have also make several additional improvements. it needs to be tested more, but since the deadline is coming up so soon, I wanted to post an update just to keep everyone abreast of what I'm doing. Please review and let me know what I need to change to get it applied to CVS. As before, this patch requires that pg_autovacuum.c and .h are moved from contrib to src/backend/postmaster and src/include/postmaster respectively. I have also attached the pg_autovacuum.h file that needs to be put in src/include/catelog/ for the new pg_autovacuum system table. I assume I will have to write the docs for this, but right now I'm focusing on the code, I get get the docs written after the feature freeze. Matthew O'Connor [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Don't 'kill -9' the postmaster
Re: [PATCHES] Docs additions: tablespace examples
Patch applied. Thanks. --- Gavin Sherry wrote: Tablespace examples for CREATE TABLE/INDEX/SCHEMA/DATABASE as well as some other examples for CREATE DATABASE. Gavin !DSPAM:40e6501e286851292611956! Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) !DSPAM:40e6501e286851292611956! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 7: don't forget to increase your free space map settings
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Please remove that; if I thought either one was a good idea, I would have allowed it in the committed patch. Sequences are too small to be worth moving around, and may someday be reimplemented in a fashion that doesn't use up a separate disk file for each one. If we allow SET TABLESPACE on them we will be limiting our future flexibility for no useful gain. Why do we allow them to be created in tablespaces in the first place then? Seems like a bit of a misfeature? I mean we don't allow views in tablespaces... Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Does this patch allow setting the tablespace of sequences as well? If so, then you will need to modify pg_dump of SERIAL sequences. Perhaps output a ALTER TABLE/SET TABLESPACE command after the CREATE TABLE definition to move the SERIAL sequence. The same argument applies if it allows moving indexes. (Unique and Primary Keys) Sequences no, toast tables no, indexes yes. So we need the latter part of the above-mentioned patch. Anyone? I'll do it. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Christopher Kings-Lynne wrote: Please remove that; if I thought either one was a good idea, I would have allowed it in the committed patch. Sequences are too small to be worth moving around, and may someday be reimplemented in a fashion that doesn't use up a separate disk file for each one. If we allow SET TABLESPACE on them we will be limiting our future flexibility for no useful gain. Why do we allow them to be created in tablespaces in the first place then? Seems like a bit of a misfeature? I mean we don't allow views in tablespaces... True, that does seem unusual. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] FW: Initdb patch
Patch applied. Thanks.
I had to manually apply your patch, and I adjusted how you set
effective_user.
---
Magnus Hagander wrote:
Here you go.
-Original Message-
From: Dave Page [mailto:[EMAIL PROTECTED]
Sent: den 8 juli 2004 15:14
To: Magnus Hagander
Subject:Initdb patch
initdb.patch
Content-Description: initdb.patch
[ Attachment, skipping... ]
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (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/initdb/initdb.c
===
RCS file: /cvsroot/pgsql-server/src/bin/initdb/initdb.c,v
retrieving revision 1.41
diff -c -c -r1.41 initdb.c
*** src/bin/initdb/initdb.c 1 Jul 2004 00:51:36 - 1.41
--- src/bin/initdb/initdb.c 12 Jul 2004 01:29:19 -
***
*** 1137,1143
PG_CMD_OPEN;
if (fprintf(pg,
! ALTER USER \%s\ WITH PASSWORD '%s';\n, username, pwd1) 0)
{
/* write failure */
exit_nicely();
--- 1137,1143
PG_CMD_OPEN;
if (fprintf(pg,
! ALTER USER \%s\ WITH PASSWORD '%s';\n, effective_user, pwd1) 0)
{
/* write failure */
exit_nicely();
***
*** 1433,1439
PG_CMD_OPEN;
priv_lines = replace_token(privileges_setup,
! $POSTGRES_SUPERUSERNAME,
username);
for (line = priv_lines; *line != NULL; line++)
PG_CMD_PUTLINE;
--- 1433,1439
PG_CMD_OPEN;
priv_lines = replace_token(privileges_setup,
! $POSTGRES_SUPERUSERNAME,
effective_user);
for (line = priv_lines; *line != NULL; line++)
PG_CMD_PUTLINE;
***
*** 2002,2010
exit(1);
}
! effective_user = get_id();
! if (!strlen(username))
! username = effective_user;
if (strlen(encoding))
encodingid = get_encoding_id(encoding);
--- 2002,2011
exit(1);
}
! if (strlen(username))
! effective_user = username;
! else
! effective_user = get_id();
if (strlen(encoding))
encodingid = get_encoding_id(encoding);
***
*** 2033,2039
PG_VERSION,
pg_data, share_path, bin_path,
encoding, encodingid,
! username, bki_file,
desc_file, conf_file,
hba_file, ident_file);
if (show_setting)
--- 2034,2040
PG_VERSION,
pg_data, share_path, bin_path,
encoding, encodingid,
! effective_user, bki_file,
desc_file, conf_file,
hba_file, ident_file);
if (show_setting)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Will toast go in the same tablespace as the base table? I can see some advantages to splitting that to another drive for extreme cases (think heap/toast lookups over and over again). --- Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Sequences are too small to be worth moving around, and may someday be reimplemented in a fashion that doesn't use up a separate disk file for each one. If we allow SET TABLESPACE on them we will be limiting our future flexibility for no useful gain. Why do we allow them to be created in tablespaces in the first place then? Seems like a bit of a misfeature? I mean we don't allow views in tablespaces... I had forgotten that the original patch allowed that. Personally I'd vote for taking it out, for the above-stated reasons --- any objections? If people do want to have it then we can instead change ALTER SET TABLESPACE to allow sequences; but we'd also need a nontrivial addition to pg_dump, so there had better be a better reason than might be nice to have. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: 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] Updated ALTER TABLE ... SET TABLESPACE patch
On Mon, 12 Jul 2004, Christopher Kings-Lynne wrote: I had forgotten that the original patch allowed that. Personally I'd vote for taking it out, for the above-stated reasons --- any objections? I vote for taking it out. Pull it. I added it intentionally but now I'm questioning my reasoning (which was, sequences might be accessed lots, people might want to put them somewhere intentionally). Chris !DSPAM:40f1f2de259842510072165! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Bruce Momjian [EMAIL PROTECTED] writes: Will toast go in the same tablespace as the base table? That is the current design, and I'd prefer to keep it that way because anything else adds great complexity for unclear gain. Two examples of pain points: 1. That pending patch to report a table's tablespace in psql \d would get lots more complex: you'd have up to three tablespaces to worry about (base table, toast table, toast index). 2. How would pg_dump restore such a setup? It could not generate a script that says ALTER TABLE pg_toast.pg_toast_NNN SET TABLESPACE, because it has no way to know what NNN should be. I think we'd have to add locutions like ALTER TABLE foo SET TOAST TABLESPACE t and ALTER TABLE foo SET TOAST INDEX TABLESPACE t to do this in a clean fashion. In fact, now that I think of it, the patch-as-committed already introduces some serious headaches for pg_dump: it can't know for sure what name will be assigned to constraint indexes (pkey and unique indexes) so it has no good way to emit ALTER TABLE SET TABLESPACE commands for those indexes. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Gavin Sherry [EMAIL PROTECTED] writes: On Mon, 12 Jul 2004, Christopher Kings-Lynne wrote: I vote for taking it out. Pull it. I added it intentionally but now I'm questioning my reasoning (which was, sequences might be accessed lots, people might want to put them somewhere intentionally). I thought about that, but AFAICS a heavily used sequence would merely end up as a single hot entry in the shared buffer arena (or at worst, an often-hit page in kernel buffers). It could not result in a lot of actual I/O because it's only one page; at most one would expect one write per checkpoint cycle. So putting it on particularly fast disk would be a useless exercise. regards, tom lane ---(end of broadcast)--- TIP 3: 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] Updated ALTER TABLE ... SET TABLESPACE patch
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Otherwise, we need to extend the ADD CONSTRAINT syntax. Yeah, I was wondering if there was some minimal-impact way to do that. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
In fact, now that I think of it, the patch-as-committed already introduces some serious headaches for pg_dump: it can't know for sure what name will be assigned to constraint indexes (pkey and unique indexes) so it has no good way to emit ALTER TABLE SET TABLESPACE commands for those indexes. I guess I'll have to make it punt that the name will be what it currently is :( Otherwise, we need to extend the ADD CONSTRAINT syntax. That would be handy because the you could specify the TABLESPACE at creation time as well. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Otherwise, we need to extend the ADD CONSTRAINT syntax. Yeah, I was wondering if there was some minimal-impact way to do that. Oh, or we create ALTER CONSTRAINT :) Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Updated ALTER TABLE ... SET TABLESPACE patch
Otherwise, we need to extend the ADD CONSTRAINT syntax. Yeah, I was wondering if there was some minimal-impact way to do that. Shall I hold off on doing any pg_dump changes then? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
