Re: [HACKERS] [CYGWIN] ipc-daemon
Richard, On Sat, Nov 16, 2002 at 02:27:22PM -0800, Richard Pais wrote: Just an explanation in the FAQ that the ipc-daemon is not running won't suffice. Because in my case I had ipc-daemon (version 1.11) running and it still hung (Jason's patch reported the IpcMemoryCreate error). Only when I downgraded to version 1.09 (office) and upgraded to 1.13 (home) did initdb succeed. So I'd suggest also covering this scenario. If you feel strongly about the above, then submit a patch to pgsql-patches@ for consideration. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] DECLARE CURSOR
Hello,
is it planed cursor out of a transaction in 7.4 ?
Thanks
Haris Peco
On Monday 18 November 2002 12:30 am, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Let's just fix it and roll an RC2 with the fix. If not, we can just fix
it in 7.3.1 but I see little problem in rolling an RC2.
Here is the patch I am testing (in current sources; I don't think it
needs any adjustments for REL7_3, but haven't tried to apply it yet).
Basically it moves the test that was originally done in parse/analyze.c
into the execution-time setup of a cursor, and enlarges the test to
understand about autocommit-off and inside-a-function exceptions.
Anyone see a problem?
regards, tom lane
*** src/backend/access/transam/xact.c.origWed Nov 13 10:51:46 2002
--- src/backend/access/transam/xact.c Sun Nov 17 19:10:20 2002
***
*** 1488,1493
--- 1488,1537
}
}
+ /*
+ * RequireTransactionChain
+ *
+ * This routine is to be called by statements that must run inside
+ * a transaction block, because they have no effects that persist past
+ * transaction end (and so calling them outside a transaction block
+ * is presumably an error). DECLARE CURSOR is an example.
+ *
+ * If we appear to be running inside a user-defined function, we do not
+ * issue an error, since the function could issue more commands that make
+ * use of the current statement's results. Thus this is an inverse for
+ * PreventTransactionChain.
+ *
+ * stmtNode: pointer to parameter block for statement; this is used in
+ * a very klugy way to determine whether we are inside a function.
+ * stmtType: statement type name for error messages.
+ *
+ */
+ void
+ RequireTransactionChain(void *stmtNode, const char *stmtType)
+ {
+ /*
+ * xact block already started?
+ */
+ if (IsTransactionBlock())
+ return;
+ /*
+ * Are we inside a function call? If the statement's parameter block
+ * was allocated in QueryContext, assume it is an interactive command.
+ * Otherwise assume it is coming from a function.
+ */
+ if (!MemoryContextContains(QueryContext, stmtNode))
+ return;
+ /*
+ * If we are in autocommit-off mode then it's okay, because this
+ * statement will itself start a transaction block.
+ */
+ if (!autocommit !suppressChain)
+ return;
+ /* translator: %s represents an SQL statement name */
+ elog(ERROR, %s may only be used in begin/end transaction blocks,
+ stmtType);
+ }
+
/*
* transaction block support
*** /home/postgres/pgsql/src/backend/tcop/pquery.c.orig Wed Sep 4 17:30:43
2002 --- /home/postgres/pgsql/src/backend/tcop/pquery.c Sun Nov 17 19:10:26
2002 ***
*** 161,166
--- 161,168
/* If binary portal, switch to alternate output format */
if (dest == Remote parsetree-isBinary)
dest = RemoteInternal;
+ /* Check for invalid context (must be in transaction block) */
+ RequireTransactionChain((void *) parsetree, DECLARE CURSOR);
}
else if (parsetree-into != NULL)
{
*** /home/postgres/pgsql/src/include/access/xact.h.orig Wed Nov 13 10:52:07
2002 --- /home/postgres/pgsql/src/include/access/xact.h Sun Nov 17 19:10:13
2002 ***
*** 115,120
--- 115,121
extern void UserAbortTransactionBlock(void);
extern void AbortOutOfAnyTransaction(void);
extern void PreventTransactionChain(void *stmtNode, const char
*stmtType); + extern void RequireTransactionChain(void *stmtNode, const
char *stmtType);
extern void RecordTransactionCommit(void);
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] pg_dump in 7.4
On Sat, 2002-11-16 at 15:49, Alvaro Herrera wrote: On Fri, Nov 15, 2002 at 11:43:47AM -0500, Rod Taylor wrote: Below is a summary of what pg_depend tracks that might be useful. Skipped a number of dependencies that are internal only (ie. toast table dependencies) as they will be regenerated correctly if their 'owners' are generated correctly. Tables depend on: - Namespace - Parent tables (if inheritance) And columns? I only see table dependencies. tablecmds.c line 943 Indexes depend on: - Constraint (where unique / primary key constraint) - Index procedure - Index operator - Attributes of indexed relation On function if functional maybe? (Is this procedure?) Yes, forgot that marker beside 'Index Procedure'. -- Rod Taylor [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] char(n) to varchar or text conversion should strip trailing spaces
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: One alternate possible approach would maybe be to change the on-disk representation to really be binary compatible and change the input output and operator functions ? Hmm ... now that's an interesting thought. So the input converter would actively strip trailing blanks, output would add them back, and only in a few char(n)-specific functions would we need to pretend they are there. This would mean that char(n)-to-text is binary compatible but the reverse direction is not (it must strip trailing blanks) --- but that coercion could be folded into the existing length-limit checker for char(n) columns. IIRC fixed width optimizations do not gain as much as in earlier versions anyway. There are no fixed-width optimizations for char(n) at all, now that we have multibyte enabled all the time. Seems like a great idea to me. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [CYGWIN] ipc-daemon
Just an explanation in the FAQ that the ipc-daemon is not running won't suffice. Because in my case I had ipc-daemon (version 1.11) running and it still hung (Jason's patch reported the IpcMemoryCreate error). Only when Idowngradedto version 1.09 (office) and upgraded to 1.13 (home) did initdb succeed. So I'd suggestalsocovering this scenario. Thanks,Richard Bruce Momjian [EMAIL PROTECTED] wrote: At least that is an FAQ item.---Jason Tishler wrote: Tom, Peter, On Mon, Nov 04, 2002 at 03:05:25PM -0500, Jason Tishler wrote: On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote: If you can detect that cygipc is not running, then ENOSYS seems the best choice for reporting that. (ENOSPC would be misleading too.)Thanks for your feedback. I will take this to the Cygwin list and see what happens. I happy to report that the above has been accomplished: http://cygwin.com/ml/cygwin-announce/2002-11/msg00025.html Hopefully, the Cygwin initdb and postmaster hang posts will be a thing of the past. Unfortunately, they probab ly will be replaced by questions like: Why does initdb fail with "IpcMemoryCreate: shmget(...) failed: Function not implemented?" Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(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 5: Have you checked our extensive FAQ?http://www.postgresql.org/user s-lounge/docs/faq.htmlDo you Yahoo!? Yahoo! Web Hosting - Let the expert host your site
Re: [HACKERS] [CYGWIN] ipc-daemon
Richard Pais [EMAIL PROTECTED] wrote: Just an explanation in the FAQ that the ipc-daemon is not running won't suffice. Because in my case I had ipc-daemon (version 1.11) running and it still hung (Jason's patch reported the IpcMemoryCreate error). Only when I downgraded to version 1.09 (office) and upgraded to 1.13 (home) did initdb succeed. So I'd suggest also covering this scenario. Thanks, Richard [...] It will. But should be augmented with REAL tests about ipc-daemon's working (cygwin's ps is not the case): - either run cygipc test suite - or check event viewer for cygipc entries (or \CYGWIN_SYSLOG.TXT and/or console in w9x case) The fact that 1.09 worked in your case, could happen because 1.09 is (maybe) more relaxed about the /tmp file permissions than others. SLao __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] DECLARE CURSOR
snpe [EMAIL PROTECTED] writes: is it planed cursor out of a transaction in 7.4 ? I do not think we will allow cross-transaction cursors ever. What would it mean to have a cross-transaction cursor, anyway? Does it show a frozen snapshot as of the time it was opened? The usefulness of that seems awfully low in comparison to the pain of implementing it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [CYGWIN] ipc-daemon
To get into the FAQ, it should be something that happens _frequently_, hence FAQ. Fact is, cygwin may not even be needed in 7.4 because we are working on a native port. --- Jason Tishler wrote: Richard, On Sat, Nov 16, 2002 at 02:27:22PM -0800, Richard Pais wrote: Just an explanation in the FAQ that the ipc-daemon is not running won't suffice. Because in my case I had ipc-daemon (version 1.11) running and it still hung (Jason's patch reported the IpcMemoryCreate error). Only when I downgraded to version 1.09 (office) and upgraded to 1.13 (home) did initdb succeed. So I'd suggest also covering this scenario. If you feel strongly about the above, then submit a patch to pgsql-patches@ for consideration. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [GENERAL] DECLARE CURSOR
Haris Peco wrote: On Monday 18 November 2002 02:38 pm, Tom Lane wrote: snpe [EMAIL PROTECTED] writes: is it planed cursor out of a transaction in 7.4 ? I do not think we will allow cross-transaction cursors ever. What would it mean to have a cross-transaction cursor, anyway? Does it show a frozen snapshot as of the time it was opened? The usefulness of that seems awfully low in comparison to the pain of implementing it. regards, tom lane It is in TODO list. Can You implement this with savepoint ? I am planning on doing savepoints for 7.4. -- 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]
[HACKERS] PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)
David Wheeler [EMAIL PROTECTED] writes: On Monday, November 18, 2002, at 08:19 AM, Tom Lane wrote: There are various ways to retrieve the datatypes of the columns of a table, but I'm not sure how that helps you to determine the parameter types for an arbitrary SQL command to be prepared. Are you assuming a specific structure of the command you want to prepare? Ouch, good point. I don't want to go there. It's a shame, really, but in light of this requirement, I don't see how PostgreSQL prepared statements can be supported by the DBI. Pity; I was really looking forward to the performance boost. Thinking about this, it occurs to me that there's no good reason why we couldn't allow parameter symbols ($n) to be considered type UNKNOWN initially. The type interpretation algorithms would then treat them just like quoted literal constants. After parsing finishes, PREPARE could scan the tree to see what type each symbol had been cast to. (You'd have to raise an error if multiple appearances of the same symbol had been cast to different types, but that'd be an uncommon case.) This form of PREPARE would presumably need some way of reporting back the types it had determined for the symbols; anyone have a feeling for the appropriate API for that? 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: [HACKERS] PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)
On Monday, November 18, 2002, at 08:58 AM, Tom Lane wrote:
Thinking about this, it occurs to me that there's no good reason why
we couldn't allow parameter symbols ($n) to be considered type UNKNOWN
initially. The type interpretation algorithms would then treat them
just like quoted literal constants. After parsing finishes, PREPARE
could scan the tree to see what type each symbol had been cast to.
(You'd have to raise an error if multiple appearances of the same
symbol
had been cast to different types, but that'd be an uncommon case.)
This form of PREPARE would presumably need some way of reporting back
the types it had determined for the symbols; anyone have a feeling for
the appropriate API for that?
If I'm understanding you correctly this approach would make it much
easier on dynamic drivers such as DBI and JDBC. Ideally, in DBI, I'd be
able to do something like this:
PREPARE my_stmt AS
SELECT foo, bar
FROM bat
WHERE foo = $1
AND bar = $2;
EXECUTE my_stmt('foo_val', 'bar_val');
It would be the responsibility of the PostgreSQL PREPARE parser to
handle the data typing of $1 and $2, and the responsibility of the DBI
client to pass in data of the appropriate type.
Is this along the lines of what you're thinking, Tom?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
---(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: [HACKERS] [GENERAL] DECLARE CURSOR
On Monday 18 November 2002 03:45 pm, Bruce Momjian wrote: Haris Peco wrote: On Monday 18 November 2002 02:38 pm, Tom Lane wrote: snpe [EMAIL PROTECTED] writes: is it planed cursor out of a transaction in 7.4 ? I do not think we will allow cross-transaction cursors ever. What would it mean to have a cross-transaction cursor, anyway? Does it show a frozen snapshot as of the time it was opened? The usefulness of that seems awfully low in comparison to the pain of implementing it. regards, tom lane It is in TODO list. Can You implement this with savepoint ? I am planning on doing savepoints for 7.4. great. Is it possible with savepoints next : when am I in transaction and any command is error - only this command is lost and I continue normal ? Thanks Haris Peco ---(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: [HACKERS] [CYGWIN] ipc-daemon
Bruce, On Mon, Nov 18, 2002 at 10:42:30AM -0500, Bruce Momjian wrote: To get into the FAQ, it should be something that happens _frequently_, hence FAQ. Understood. That is why is said for consideration. Fact is, cygwin may not even be needed in 7.4 because we are working on a native port. A Win32 native port in the 7.4 time frame is great news! However, I hope that the Cygwin port will not be deprecated. There are compelling reasons to still have a Cygwin PostgreSQL port just like there is with Python, Perl, Vim, Emacs, etc. On the other hand, I wouldn't mind being put out of the Cygwin PostgreSQL support business... :,) Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [CYGWIN] ipc-daemon
Jason Tishler wrote: Bruce, On Mon, Nov 18, 2002 at 10:42:30AM -0500, Bruce Momjian wrote: To get into the FAQ, it should be something that happens _frequently_, hence FAQ. Understood. That is why is said for consideration. Fact is, cygwin may not even be needed in 7.4 because we are working on a native port. A Win32 native port in the 7.4 time frame is great news! However, I hope that the Cygwin port will not be deprecated. There are compelling reasons to still have a Cygwin PostgreSQL port just like there is with Python, Perl, Vim, Emacs, etc. On the other hand, I wouldn't mind being put out of the Cygwin PostgreSQL support business... :,) I see no reason to remove cygwin support. I assume they will both continue to exist. -- 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: [HACKERS] [GENERAL] DECLARE CURSOR
is it planed cursor out of a transaction in 7.4 ? I do not think we will allow cross-transaction cursors ever. What would it mean to have a cross-transaction cursor, anyway? Does it show a frozen snapshot as of the time it was opened? The usefulness of that seems awfully low in comparison to the pain of implementing it. It is usually used with comitted read isolation for an outer select on one table and one transaction per row where the action usually involving additional tables depends on the selected row. This is to keep transactions small and avoid locking out other activity. The outer cursor is declared WITH HOLD. I think it is a useful feature. Of course a workaround is to open two connections. Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CLUSTER ALL syntax
Alvaro Herrera wrote: On Sun, Nov 17, 2002 at 04:42:01PM -0500, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: In looking at the CLUSTER ALL patch I have applied, I am now wondering why the ALL keyword is used. When we do VACUUM, we don't use ALL. VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing. I agree, lose the ALL. Well, in my original patch (the one submitted just when 7.3 was going into beta) there was no ALL. I decided to put it in for subsequent patches for no good reason. I have updated CVS to make the syntax CLUSTER rather than CLUSTER ALL. -- 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/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] DECLARE CURSOR
On Monday 18 November 2002 05:46 pm, Bruce Momjian wrote: Haris Peco wrote: great. Is it possible with savepoints next : when am I in transaction and any command is error - only this command is lost and I continue normal ? Yes, that will be part of it. I am working on my proposal today. Fine.What about cursor out of a transaction ? That is not part of my work. Is it planned UNDO (WAL) ? Thanks Haris Peco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Getting float8 data into cube?
On Sun, Nov 17, 2002 at 15:19:54 -0500, Tom Lane [EMAIL PROTECTED] wrote: Bruno Wolff III [EMAIL PROTECTED] writes: For 7.4 I would like to add a function for importing float8 values into cube. But because the cube data type is variable length I am not sure what a good approach would be. I'm not clear on what you want to accomplish. How are you expecting the source data to be structured? regards, tom lane I would like to get the results of floating point calculations into a cube without losing precision because float output is trunctated at 15 digits. In 7.4 I will have the option to change extra_float_digits while loading data into cubes, but that seems like a hack. My particular case will be converting latitude and longitude to 3D cartesian coordinates. With the calculations truncated at 15 digits, I can sometimes see round off error after going back to latitude and longitude. The accurracy itself isn't a big deal, it is more seeing the .001 or .99 at the end of the numbers that is annoying. This could also be handled by further rounding. It also seems like there should be a way to get floating point data into cube without losing precision. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] char(n) to varchar or text conversion should strip trailing spaces
I said:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
One alternate possible approach would maybe be to change the on-disk
representation to really be binary compatible and change the input
output and operator functions ?
Seems like a great idea to me.
On further thought I've got some reservations about it. The main
problem is that the physical contents of a char(n) Datum wouldn't
provide the complete semantic meaning: you must know the typmod as well
to know the number of padding spaces that are supposed to be there.
We have special provisions to allow input and output functions to know
the typmod, but in more general cases functions will not receive a
typmod, and in any case they cannot deliver a typmod. So for any
operation that wanted to behave as though the padding spaces are real,
there'd be a problem.
We could maybe play some games with having char(n) values be expanded
(space-padded) during expression evaluation and then trimmed for
storage, but this strikes me as awfully messy, not to mention redundant
with the compression done by TOAST.
Also: I've been reading through the spec in more detail, and what I now
realize is that they expect trailing blanks to be ignored by default in
both char(n) and varchar(n) comparisons! In fact, it's not really the
datatype that determines this, but the collation attribute, and they
specify that the default collation must have the PAD SPACE attribute
(which essentially means that trailing spaces are not significant).
What's more, AFAICT padding spaces in char(n) are treated as real data
by every operation except comparison --- for example, they are real
data in concatenation.
I don't think we really want to meet the letter of the spec here :-(
It seems quite schizoid to treat pad spaces as real data for everything
except comparison. Certainly I do not want to do that for varchar or
text datatypes.
The idea of having char(n)-to-text conversion strip trailing blanks
still appeals to me, but I have to withdraw the claim that it'd improve
our spec compliance; it wouldn't.
I'm now wondering whether it wouldn't be better to leave the data
representation as-is (padding spaces are stored), and still allow binary
compatibility both ways, but add a collection of duplicate pg_proc and
pg_operator entries so that char-ness is preserved where appropriate.
For example, we'd need both these pg_proc entries for UPPER():
upper(text) returns text
upper(character) returns character
They could point at the same C routine, but the parser would select the
first when the input is text or varchar, and the second when the input
is character. This would solve the original complaint about
upper('foo '::char(6)) = 'FOO'
needing to yield TRUE. The extra pg_proc entries would be a tad
tedious, but I think we'd only need a couple dozen to satisfy the spec's
requirements. Some (perhaps not all) of these functions would need to
be duplicated:
btrim(text)
btrim(text,text)
convert(text,name)
convert(text,name,name)
convert_using(text,text)
initcap(text)
lower(text)
lpad(text,integer)
lpad(text,integer,text)
ltrim(text)
ltrim(text,text)
max(text)
min(text)
overlay(text,text,integer)
overlay(text,text,integer,integer)
repeat(text,integer)
replace(text,text,text)
rpad(text,integer)
rpad(text,integer,text)
rtrim(text)
rtrim(text,text)
split_part(text,text,integer)
substr(text,integer)
substr(text,integer,integer)
substring(text,integer)
substring(text,integer,integer)
text_larger(text,text)
text_smaller(text,text)
textcat(text,text)
translate(text,text,text)
upper(text)
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Final Release Scheduale ...
Morning all ... Well, we're finally coming to the end of yet another release cycle ... right now, baring any problems creeping up, we're planning on packaging up RC2 on Friday morning, with an announcement going out that evening for ppl to test and confirm everything is okay. If *no* commits to the code are made between then and Tuesday, Tuesday the 26th of November will be the wrap-up date for the final package, with the full release / press release going out first thing Wednesday morning ... Currently we have one large, closed, list of email addresses we will be using for this announcement ... but it is not necessarily a complete list of everyone we could send to ... if anyone would like to submit addresses to add, please send them directly to me with a subject header of: [PR Submit] Don't just send me the address though, tell me who the person is ... and yes, I know that ther will be a load of duplicates coming my way, but I'll sort through that ... just let me know of any addresses you can think of that we shoudl submit to, and I'll worry about whether I might already have them on our list :) Another week to go folks ... :) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [GENERAL] DECLARE CURSOR
Haris Peco wrote: On Monday 18 November 2002 03:45 pm, Bruce Momjian wrote: Haris Peco wrote: On Monday 18 November 2002 02:38 pm, Tom Lane wrote: snpe [EMAIL PROTECTED] writes: is it planed cursor out of a transaction in 7.4 ? I do not think we will allow cross-transaction cursors ever. What would it mean to have a cross-transaction cursor, anyway? Does it show a frozen snapshot as of the time it was opened? The usefulness of that seems awfully low in comparison to the pain of implementing it. regards, tom lane It is in TODO list. Can You implement this with savepoint ? I am planning on doing savepoints for 7.4. great. Is it possible with savepoints next : when am I in transaction and any command is error - only this command is lost and I continue normal ? Yes, that will be part of it. I am working on my proposal today. -- 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/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] DECLARE CURSOR
On Monday 18 November 2002 05:38 pm, Bruce Momjian wrote: Haris Peco wrote: On Monday 18 November 2002 03:45 pm, Bruce Momjian wrote: Haris Peco wrote: On Monday 18 November 2002 02:38 pm, Tom Lane wrote: snpe [EMAIL PROTECTED] writes: is it planed cursor out of a transaction in 7.4 ? I do not think we will allow cross-transaction cursors ever. What would it mean to have a cross-transaction cursor, anyway? Does it show a frozen snapshot as of the time it was opened? The usefulness of that seems awfully low in comparison to the pain of implementing it. regards, tom lane It is in TODO list. Can You implement this with savepoint ? I am planning on doing savepoints for 7.4. great. Is it possible with savepoints next : when am I in transaction and any command is error - only this command is lost and I continue normal ? Yes, that will be part of it. I am working on my proposal today. Fine.What about cursor out of a transaction ? Thanks Haris Peco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] DECLARE CURSOR
Haris Peco wrote: great. Is it possible with savepoints next : when am I in transaction and any command is error - only this command is lost and I continue normal ? Yes, that will be part of it. I am working on my proposal today. Fine.What about cursor out of a transaction ? That is not part of my work. -- 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]
[HACKERS] Ideas needed: How to create and store collation tables
I am trying to figure out which is the best way to store custom collation tables on a PostgreSQL server system, and what kind of interface to provide to users to allow them to create their own. A collation table essentially consists of a mapping 'character code - weight' for every character in the set and some additional considerations for one-to-many and many-to-one mappings, plus a few feature flags. How would a user go about creating such a table? CREATE COLLATION foo ( ... 1 lines of data ... ); or would it be preferrable to store the table in some external file and then have the call simply be, say, CREATE COLLATION foo SOURCE 'some file'; The latter has the disadvantage that we'd need some smarts so that pg_dump would not repeat the mistakes that were made with dynamically loadable modules (such as absolute file paths). The former has the disadvantage that it is too unwieldy to be useful. We also need to consider the following two problems: Firstly, if the collation data -- no matter how it is created -- is stored within the database (that is, in some table(s)), then it would be duplicated in every database. Depending on the storage format, a collation table takes between around 100 kB and 800 kB. Multiply that by a few dozen languages, for each database. That would make an external file seem more attractive. (The external file would need to be a binary file that is precomputed for efficient processing, unless we want to reparse and reprocess it every so often, like for every session.) Secondly, because each collation table depends on a particular character encoding (since it is indexed by character code), some sort of magic needs to happen when someone creates a database with a different encoding than the template database. One option is to do some mangling on the registered external file name (such as appending the encoding name to the file name). Another option is to have the notional pg_collate system catalog contain a column for the encoding, and then simply ignore all entries pertaining to encodings other than the database encoding. Comments or better ideas? -- Peter Eisentraut [EMAIL PROTECTED] ---(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: [HACKERS] char(n) to varchar or text conversion should strip
Tom Lane writes: Hmm ... now that's an interesting thought. So the input converter would actively strip trailing blanks, output would add them back, But how would the output know how many to put back? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [CYGWIN] ipc-daemon
Bruce Momjian writes: To get into the FAQ, it should be something that happens _frequently_, Just check the pgsql-cygwin archives. We really need a separate list of Constantly Asked Questions for this. -- Peter Eisentraut [EMAIL PROTECTED] ---(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: [HACKERS] char(n) to varchar or text conversion should strip
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Hmm ... now that's an interesting thought. So the input converter would actively strip trailing blanks, output would add them back, But how would the output know how many to put back? The output routine would need access to the column typmod. Which it would have, in simple SELECT columnname cases, but this is a serious weakness of the scheme in general. See my followup post of a few minutes ago. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] DECLARE CURSOR
Haris Peco wrote: On Monday 18 November 2002 05:46 pm, Bruce Momjian wrote: Haris Peco wrote: great. Is it possible with savepoints next : when am I in transaction and any command is error - only this command is lost and I continue normal ? Yes, that will be part of it. I am working on my proposal today. Fine.What about cursor out of a transaction ? That is not part of my work. Is it planned UNDO (WAL) ? No, see TODO.detail/transactions for info, or wait for my posting later today. -- 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: [HACKERS] Ideas needed: How to create and store collation tables
On Mon, 18 Nov 2002, Peter Eisentraut wrote: A collation table essentially consists of a mapping 'character code - weight' for every character in the set and some additional considerations for one-to-many and many-to-one mappings, plus a few feature flags. How would a user go about creating such a table? CREATE COLLATION foo ( ... 1 lines of data ... ); or would it be preferrable to store the table in some external file and then have the call simply be, say, CREATE COLLATION foo SOURCE 'some file'; I'd say the latter makes more sense, but would it be better to use CREATE COLLATION foo FROM EXTERNAL 'some file'; where we say valid implementation defined collation names are references to files of the appropriate type? Secondly, because each collation table depends on a particular character encoding (since it is indexed by character code), some sort of magic needs to happen when someone creates a database with a different encoding than the template database. One option is to do some mangling on the registered external file name (such as appending the encoding name to the file name). Another option is to have the notional pg_collate system catalog contain a column for the encoding, and then simply ignore all entries pertaining to encodings other than the database encoding. The SQL92 CREATE COLLATION seems to create a collation for a particular character set, so the latter seems more appropriate to me, especially if we plan to support the full range of SQL's character set/collation/padding attributes at some point. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Ideas needed: How to create and store collation tables
Peter Eisentraut [EMAIL PROTECTED] writes: I am trying to figure out which is the best way to store custom collation tables on a PostgreSQL server system, and what kind of interface to provide to users to allow them to create their own. A collation table essentially consists of a mapping 'character code - weight' for every character in the set and some additional considerations for one-to-many and many-to-one mappings, plus a few feature flags. I'd be inclined to handle it similarly to the way that Tatsuo did with conversion_procs: let collations be represented by comparison functions that meet some suitable API. I think that trying to represent such a table as an SQL table compactly will be a nightmare, and trying to access it quickly enough for reasonable performance will be worse. Keep the problem out of the API and let each comparison function do what it needs to do internally. Secondly, because each collation table depends on a particular character encoding (since it is indexed by character code), some sort of magic needs to happen when someone creates a database with a different encoding than the template database. One option is to do some mangling on the registered external file name (such as appending the encoding name to the file name). Another option is to have the notional pg_collate system catalog contain a column for the encoding, and then simply ignore all entries pertaining to encodings other than the database encoding. SQL92 says that any particular collation is applicable to only one character set (which is their term that matches our encodings). So I think we'd definitely want to associate a character set with each pg_collation entry, and then ignore any entries that don't match the DB encoding. (Further down the road, the DB encoding might change into just a default for tables in this DB encoding, meaning that we'd need access to collations for multiple encodings anyway.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Looking for a Linux on Playstation 2 person to compile PostgreSQL RPM's
Hi everyone, We know PostgreSQL will compile and run on the Sony Playstation 2, and we now have the opportunity to include pre-compiled PostgreSQL RPM's (for the Playstation 2 Linux kit) on the Sony site, as part of the Compiled For Your Convenience collection. Now, we just need someone with the Linux for Playstation 2 kit to compile the RPM's so they can be added. Does anyone already have a Linux for Playstation 2 kit and would be willing to compile them? :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [pgsql-advocacy] Looking for a Linux on Playstation 2 person
I don't have the kit, but I do have a playstation 2. If someone would be willing to donate a kit I'd be willing to try and get it to compile. :-) Robert Treat On Mon, 2002-11-18 at 16:51, Justin Clift wrote: Hi everyone, We know PostgreSQL will compile and run on the Sony Playstation 2, and we now have the opportunity to include pre-compiled PostgreSQL RPM's (for the Playstation 2 Linux kit) on the Sony site, as part of the Compiled For Your Convenience collection. Now, we just need someone with the Linux for Playstation 2 kit to compile the RPM's so they can be added. Does anyone already have a Linux for Playstation 2 kit and would be willing to compile them? :-) Regards and best wishes, Justin Clift ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] mislaid reference to update script for after 7.3 upgrade
I'm pretty sure I saw a reference within the last 3 or 4 weeks on one of the mailing lists to a script that would put in place, after an upgrade to 7.3, dependency information that would have been automatically created if the schema had been created ab initio in 7.3. However, I can't find it in a mailing list search. Can anyone give me a URL for that, or have I sdreamed it? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C To show forth thy lovingkindness in the morning, and thy faithfulness every night. Psalms 92:2 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] mislaid reference to update script for after 7.3 upgrade
Oliver Elphick wrote: I'm pretty sure I saw a reference within the last 3 or 4 weeks on one of the mailing lists to a script that would put in place, after an upgrade to 7.3, dependency information that would have been automatically created if the schema had been created ab initio in 7.3. However, I can't find it in a mailing list search. Can anyone give me a URL for that, or have I sdreamed it? See contrib/adddepend. Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Ideas needed: How to create and store collation
I'd be inclined to handle it similarly to the way that Tatsuo did with conversion_procs: let collations be represented by comparison functions that meet some suitable API. I think that trying to represent such a table as an SQL table compactly will be a nightmare, and trying to access it quickly enough for reasonable performance will be worse. Keep the problem out of the API and let each comparison function do what it needs to do internally. Agreed. That was the way I have been thinking about collation/create character stuff too. -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
