[PATCHES] update link / fix spelling error
Updates the link for the sql 2003 spec, also fixes a spelling error.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: FAQ_DEV.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_DEV.html,v
retrieving revision 1.109
diff -c -r1.109 FAQ_DEV.html
*** FAQ_DEV.html 1 Mar 2006 22:24:51 - 1.109
--- FAQ_DEV.html 7 Jun 2006 21:19:29 -
***
*** 199,205
"#1.16">1.16.
If you are adding a new feature, confirm that it has been tested
! thoughly. Try to test the feature in all conceivable
scenarios.
If it is a performance patch, please provide confirming test
--- 199,205
"#1.16">1.16.
If you are adding a new feature, confirm that it has been tested
! thoroughly. Try to test the feature in all conceivable
scenarios.
If it is a performance patch, please provide confirming test
***
*** 704,710
http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf
SQL:2003 http://www.wiscorp.com/sql/sql_2003_standard.zip";>http://www.wiscorp.com/sql/sql_2003_standard.zip
Some SQL standards web pages are:
--- 704,710
http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf
SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip";>http://www.wiscorp.com/sql_2003_standard.zip
Some SQL standards web pages are:
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] remove lock protection on HeapTupleSatisfiesVacuum
""Jim C. Nasby"" <[EMAIL PROTECTED]> wrote > > Maybe a comment patch would be in order to prevent future confusion? > Not really needed because the buffer/README access rule#1 has already said that ... Regards, Qingqing ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] drop if exists remainder
Tom, > > > What's the consensus on this? Nobody else has chimed in, so I'm > > > inclined to do no more on the gounds of insufficient demand. Let's > > > decide before too much bitrot occurs, though. > > > > +1 :) > > +1 We were talking about this on IRC, and I feel that if we're going to do "IF EXISTS" for any objects, we should do it for all objects. Otherwise we risk a considerable amount of user confusion. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] drop if exists remainder
On Saturday 04 March 2006 22:24, David Fetter wrote:
> On Fri, Mar 03, 2006 at 03:35:24PM -0500, Andrew Dunstan wrote:
> > Bruce Momjian wrote:
> > >Christopher Kings-Lynne wrote:
> >
> > What's the consensus on this? Nobody else has chimed in, so I'm inclined
> > to do no more on the gounds of insufficient demand. Let's decide before
> > too much bitrot occurs, though.
>
> +1 :)
>
+1
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] TODO-Item: full timezone names
Patch applied. Thanks. --- Joachim Wieland wrote: > On Thu, Jun 01, 2006 at 12:35:44PM -0400, Tom Lane wrote: > > Joachim Wieland <[EMAIL PROTECTED]> writes: > > > I'm talking about the timetz type that does not carry a date. So you don't > > > know if daylight savings time is active or not. How would you interpret > > > the > > > full timezone in this case without a date? > > > Oh, doh, I managed to miss that detail. Yeah, you're right, you need an > > arbitrary assumption in that case. Or we could forbid these timezones > > in timetz input, but that's probably not very helpful. > > After sending my last mail, I concluded that it was in fact me who missed > something and that you were right. I came to the conclusion that you were > talking about the fact that you can specify a timetz also with a date: > > template1=# select '2006-06-01 10:49 America/New_York'::timetz; >timetz > - > 10:49:00-04 > > This date can then be used to infer the timezone: > > template1=# select '2006-03-01 10:49 America/New_York'::timetz; >timetz > - > 10:49:00-05 > > I have updated my patch to do so. Just specifying a timestamp > > select '10:49 America/New_York'::timetz; > > does now return an error. > > Is that a suitable compromise? > > > > Joachim > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] fix minor spelling issues in FAQ
Robert Treat wrote: > Attached patch fixes a couple of spelling mistakes in the FAQ Thanks, applied. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
[PATCHES] fix minor spelling issues in FAQ
Attached patch fixes a couple of spelling mistakes in the FAQ
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: FAQ.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ.html,v
retrieving revision 1.347
diff -c -r1.347 FAQ.html
*** FAQ.html 4 Jun 2006 00:17:43 - 1.347
--- FAQ.html 7 Jun 2006 21:05:09 -
***
*** 694,700
One limitation is that indexes can not be created on columns
longer than about 2,000 characters. Fortunately, such indexes are
! rarely needed. Uniqueness is best guaranteed by a funtion index
of an MD5 hash of the long column, and full text indexing
allows for searching of words within the column.
--- 694,700
One limitation is that indexes can not be created on columns
longer than about 2,000 characters. Fortunately, such indexes are
! rarely needed. Uniqueness is best guaranteed by a function index
of an MD5 hash of the long column, and full text indexing
allows for searching of words within the column.
***
*** 812,819
FROM tab
WHERE lower(col) = 'abc';
! This will not use an standard index. However, if you create a
! expresssion index, it will be used:
CREATE INDEX tabindex ON tab (lower(col));
--- 812,819
FROM tab
WHERE lower(col) = 'abc';
! This will not use an standard index. However, if you create an
! expression index, it will be used:
CREATE INDEX tabindex ON tab (lower(col));
***
*** 957,963
Every row that is created in PostgreSQL gets a unique
OID unless created WITHOUT OIDS.
! OIDs are autotomatically assigned unique 4-byte
integers that are unique across the entire installation. However,
they overflow at 4 billion, and then the OIDs start
being duplicated. PostgreSQL uses OIDs to link its
--- 957,963
Every row that is created in PostgreSQL gets a unique
OID unless created WITHOUT OIDS.
! OIDs are automatically assigned unique 4-byte
integers that are unique across the entire installation. However,
they overflow at 4 billion, and then the OIDs start
being duplicated. PostgreSQL uses OIDs to link its
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] ALTER TABLE ADD/DROP INHERITS
Greg Stark <[EMAIL PROTECTED]> writes: > I expected that but I haven't seen any agreement on a replacement syntax. The > only other one proposed was: > ALTER TABLE foo ALTER INHERITS ADD|DROP bar > and it received no comments. Should I just assume that's the direction to go > if nobody objects? I think if anyone wants something better, the onus is on them to provide a grammar patch that works ;-) regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] ALTER TABLE ADD/DROP INHERITS
Tom Lane <[EMAIL PROTECTED]> writes: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > We should try very hard to avoid adding new reserved words, IMNSHO. > > *Especially* ones not sanctioned by the SQL spec. Reserving a word that > is not listed as reserved in the standard is really a spec violation, > because it means that spec-conforming SQL commands may fail. I expected that but I haven't seen any agreement on a replacement syntax. The only other one proposed was: ALTER TABLE foo ALTER INHERITS ADD|DROP bar and it received no comments. Should I just assume that's the direction to go if nobody objects? -- greg ---(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] ALTER TABLE ADD/DROP INHERITS
Andrew Dunstan <[EMAIL PROTECTED]> writes: > We should try very hard to avoid adding new reserved words, IMNSHO. *Especially* ones not sanctioned by the SQL spec. Reserving a word that is not listed as reserved in the standard is really a spec violation, because it means that spec-conforming SQL commands may fail. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ALTER TABLE ADD/DROP INHERITS
Greg Stark wrote: As described on -hackers this is my work so far adding ADD/DROP INHERITS. It implements the controversial "ALTER TABLE ADD/DROP INHERITS " syntax that requires making INHERITS a reserved keyword. I haven't seen a clear consensus yet on what the best syntax to use here would be. We should try very hard to avoid adding new reserved words, IMNSHO. I have no idea how many users have tables or columns called "inherits", but it is surely a number greater than zero. cheers andrew ---(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
[PATCHES] ALTER TABLE ADD/DROP INHERITS
As described on -hackers this is my work so far adding ADD/DROP INHERITS. It
implements the controversial "ALTER TABLE ADD/DROP INHERITS "
syntax that requires making INHERITS a reserved keyword. I haven't seen a
clear consensus yet on what the best syntax to use here would be.
Also, it doesn't handle default column values yet.
Other than that I think it's complete. There are a number of things I'm not
completely certain I'm on the right track with though so it can certainly use
some more eyeballs on it.
Index: src/backend/commands/tablecmds.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/tablecmds.c,v
retrieving revision 1.184
diff -u -p -c -r1.184 tablecmds.c
cvs diff: conflicting specifications of output style
*** src/backend/commands/tablecmds.c10 May 2006 23:18:39 - 1.184
--- src/backend/commands/tablecmds.c7 Jun 2006 18:09:56 -
*** typedef struct NewColumnValue
*** 159,166
--- 159,168
static void truncate_check_rel(Relation rel);
static List *MergeAttributes(List *schema, List *supers, bool istemp,
List **supOids, List **supconstr, int
*supOidCount);
+ static void MergeAttributesIntoExisting(Relation rel, Relation relation);
static bool change_varattnos_of_a_node(Node *node, const AttrNumber
*newattno);
static void StoreCatalogInheritance(Oid relationId, List *supers);
+ static void StoreCatalogInheritance1(Oid relationId, Oid parentOid, int16
seqNumber, Relation catalogRelation);
static intfindAttrByName(const char *attributeName, List *schema);
static void setRelhassubclassInRelation(Oid relationId, bool relhassubclass);
static bool needs_toast_table(Relation rel);
*** static void ATPrepSetTableSpace(AlteredT
*** 246,251
--- 248,255
static void ATExecSetTableSpace(Oid tableOid, Oid newTableSpace);
static void ATExecEnableDisableTrigger(Relation rel, char *trigname,
bool enable, bool
skip_system);
+ static void ATExecAddInherits(Relation rel, RangeVar *parent);
+ static void ATExecDropInherits(Relation rel, RangeVar *parent);
static void copy_relation_data(Relation rel, SMgrRelation dst);
static void update_ri_trigger_args(Oid relid,
const char *oldname,
*** static void
*** 1156,1165
StoreCatalogInheritance(Oid relationId, List *supers)
{
Relationrelation;
- TupleDesc desc;
int16 seqNumber;
ListCell *entry;
- HeapTuple tuple;
/*
* sanity checks
--- 1160,1167
*** StoreCatalogInheritance(Oid relationId,
*** 1179,1194
* anymore, there's no need to look for indirect ancestors.)
*/
relation = heap_open(InheritsRelationId, RowExclusiveLock);
- desc = RelationGetDescr(relation);
seqNumber = 1;
foreach(entry, supers)
{
! Oid parentOid = lfirst_oid(entry);
Datum datum[Natts_pg_inherits];
charnullarr[Natts_pg_inherits];
ObjectAddress childobject,
parentobject;
datum[0] = ObjectIdGetDatum(relationId);/*
inhrel */
datum[1] = ObjectIdGetDatum(parentOid); /* inhparent */
--- 1181,1206
* anymore, there's no need to look for indirect ancestors.)
*/
relation = heap_open(InheritsRelationId, RowExclusiveLock);
seqNumber = 1;
foreach(entry, supers)
{
! StoreCatalogInheritance1(relationId, lfirst_oid(entry),
seqNumber, relation);
! seqNumber += 1;
! }
!
! heap_close(relation, RowExclusiveLock);
! }
!
! static void
! StoreCatalogInheritance1(Oid relationId, Oid parentOid, int16 seqNumber,
Relation relation)
! {
Datum datum[Natts_pg_inherits];
charnullarr[Natts_pg_inherits];
ObjectAddress childobject,
parentobject;
+ HeapTuple tuple;
+ TupleDesc desc = RelationGetDescr(relation);
datum[0] = ObjectIdGetDatum(relationId);/*
inhrel */
datum[1] = ObjectIdGetDatum(parentOid); /* inhparent */
*** StoreCatalogInheritance(Oid relationId,
*** 1222,1234
* Mark the parent as having subclasses.
*/
setRelhassubclassInRelation(parentOid, true);
- seqNumber += 1;
- }
- heap_close(relation, RowExclusiveLock);
}
/*
* Look for an existing schema entry with the given name.
*
--- 1234,1246
* Mark the parent as having subclasses.
Re: [PATCHES] remove lock protection on HeapTupleSatisfiesVacuum
On Wed, Jun 07, 2006 at 09:34:47AM +0800, Qingqing Zhou wrote: > > "Qingqing Zhou" <[EMAIL PROTECTED]> wrote > > > > The overall performance improvement might be marginal but why not if it is > > right. What I cares is the correctness. As I understand, the orginal code > > puts a shared lock (1) to prevent the vacuum process to move tuples around > > so the hint bits change may happen in a wrong place; (2) to prevent other > > operations holding EXCLUSIVE lock to change bits at the same time. > > > > I realized I made an aweful mistake. The shared lock also (3) to prevent > other operations holding EXCLUSIVE lock to change the xid fields at the > same. So the final conclusion is: the original code is right and my patch is > terriblly wrong :-( Maybe a comment patch would be in order to prevent future confusion? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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] Re [HACKERS]: Still not happy with psql's multiline history behavior
Conditional history length test removed.
---
Bruce Momjian wrote:
>
> Also, in this line from psql/mainloop.c:
>
> 312 if (scan_result == PSCAN_BACKSLASH && history_buf->len != 0)
>
> Is the "history_buf->len != 0" test necessary?
>
> ---
>
> pgman wrote:
> > Sergey E. Koposov wrote:
> > > On Sun, 4 Jun 2006, Bruce Momjian wrote:
> > >
> > > > Sergey E. Koposov wrote:
> > > >> Hello,
> > > >>
> > > >> I'm sending the patch fixing the \r bug:
> > > >
> > > > Funny, I just applied a simpler fix for the \r bug. Please review it.
> > > > Thanks.
> > > >
> > >
> > > It is simpler, because it behaves differently.
> > > Your patch for the case:
> > > wsdb=# select
> > > wsdb-# \r
> > > Query buffer reset (cleared).
> > >
> > > puts in the history two elements ("\r" and "select")
> > >
> > > Mine puts only "\r", just because
> > > \r reset (clear) the query buffer
> > > and I think that's reasonable, but I don't insist...
> >
> > I think I like the fact there two separate entries, so we are OK.
> >
> > > > I am confused by the \e bug. I just tried 8.1.X and it seems to behave
> > > > the same as CVS HEAD. What exactly should it do?
> > > >
> > >
> > > It is not actually a bug, I think it's a Tom's habit.
> > > In 8.1.x if you type for example in the editor "select 1+" and exit from
> > > it, the "select 1+" string will be already in the history. But in CVS HEAD
> > > it will be saved internally, but it won't be shown in the history until
> > > the
> > > user finishes the command with ';'. And there is really no need for
> > > correcting that, I think.
> >
> > Thanks, that was clear. The attached patch fixes it. It is a little
> > larger than usual because I changed the name of the boolean and reversed
> > its usage. It now works like it did in 8.1.X.
> >
> > --
> > Bruce Momjian http://candle.pha.pa.us
> > EnterpriseDBhttp://www.enterprisedb.com
> >
> > + If your life is a hard drive, Christ can be your backup. +
>
> [ text/x-diff is unsupported, treating like TEXT/PLAIN ]
>
> > Index: src/bin/psql/mainloop.c
> > ===
> > RCS file: /cvsroot/pgsql/src/bin/psql/mainloop.c,v
> > retrieving revision 1.75
> > diff -c -c -r1.75 mainloop.c
> > *** src/bin/psql/mainloop.c 4 Jun 2006 04:35:55 - 1.75
> > --- src/bin/psql/mainloop.c 5 Jun 2006 03:50:11 -
> > ***
> > *** 41,47
> > char *line; /* current line of input */
> > int added_nl_pos;
> > boolsuccess;
> > ! boolfirst_query_scan;
> >
> > volatile int successResult = EXIT_SUCCESS;
> > volatile backslashResult slashCmdStatus = PSQL_CMD_UNKNOWN;
> > --- 41,47
> > char *line; /* current line of input */
> > int added_nl_pos;
> > boolsuccess;
> > ! boolline_saved_in_history;
> >
> > volatile int successResult = EXIT_SUCCESS;
> > volatile backslashResult slashCmdStatus = PSQL_CMD_UNKNOWN;
> > ***
> > *** 80,85
> > --- 80,87
> > /* main loop to get queries and execute them */
> > while (successResult == EXIT_SUCCESS)
> > {
> > + line_saved_in_history = false;
> > +
> > /*
> > * Welcome code for Control-C
> > */
> > ***
> > *** 154,159
> > --- 156,163
> > */
> > pg_write_history(history_buf->data);
> > pg_clear_history(history_buf);
> > + pg_write_history(line);
> > + line_saved_in_history = true;
> > }
> > }
> > /* otherwise, get another line */
> > ***
> > *** 226,232
> > */
> > psql_scan_setup(scan_state, line, strlen(line));
> > success = true;
> > - first_query_scan = true;
> >
> > while (success || !die_on_error)
> > {
> > --- 230,235
> > ***
> > *** 303,319
> > * down here so we can check for \g and other
> > 'execute'
> > * backslash commands, which should be appended.
> > */
> > ! if (first_query_scan && pset.cur_cmd_interactive)
> > {
> > /* Sending a command (PSQL_CMD_SEND) zeros the
> > length */
> > if (scan_result == PSCAN_BACKSLASH &&
> > history_buf->len != 0)
> > pg_write_history(line);
> > else
> >
Re: [PATCHES] [HACKERS] Win32 sysconfig -> pg_service.conf
Bruce Momjian wrote: How is it different from the path we pass to it? Aren't all those paths full already? If they are then it probably doesn't matter. The reason I don't want to use GetFullPathName() is because on Unix, we just return the specified path, not the full path, so I don't want to do something different on Win32 unless we have to. There is good reason to get the short path on Win32, if we can, but no logic to returning the full path only on Win32, if that is not what was specified by configure. OK cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Win32 sysconfig -> pg_service.conf
Andrew Dunstan wrote: > >>What made you choose this rather than GetFullPathName? > >> > >> > > > >Sure, we can do that. Does GetFullPathName() work if the path does not > >exist? > > > > yes. see > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getfullpathname.asp > > > How is it different from the path we pass to it? Aren't all > >those paths full already? > > > > > > > > If they are then it probably doesn't matter. The reason I don't want to use GetFullPathName() is because on Unix, we just return the specified path, not the full path, so I don't want to do something different on Win32 unless we have to. There is good reason to get the short path on Win32, if we can, but no logic to returning the full path only on Win32, if that is not what was specified by configure. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] [HACKERS] Win32 sysconfig -> pg_service.conf
Bruce Momjian wrote: Andrew Dunstan wrote: Bruce Momjian said: On Win32, patch applied to return path if GetShortPathName() fails (no short name, path does not exist), rather than returning nothing. What made you choose this rather than GetFullPathName? Sure, we can do that. Does GetFullPathName() work if the path does not exist? yes. see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getfullpathname.asp How is it different from the path we pass to it? Aren't all those paths full already? If they are then it probably doesn't matter. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
