Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
On Mon, 15 Jul 2002, Bruce Momjian wrote: > > (In related news, how about filling up the oid/relfilenode numbers with > > zeros on the left, so a directory listing would reflect the numerical > > order?) > > Problem there is that we increase the size of much of the directory > lookups. Not sure if it is worth worrying about. Probably not such a big deal, since most systems will be reading a full block (8K or 16K under *BSD) to load the directory information anyway. Doing it in hex would give you only 8-char filenames, anyway. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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] [SQL] line datatype
> It would be nice to get the line type working 100%. Thomas says the > problem is input/output format. I don't completely understand. The issue is in choosing an external format for LINE which does not lose precision during dump/reload. Internally, LINE is described by a formula which is likely subject to problems with limited precision for some line orientations. Does anyone have a suggestion (perhaps drawn from another GIS package) for representing lines? We already have this implemented internally, and the algorithms are used to support other data types; the only unresolved issue is in how to input the values. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] bit type external representation
> > 1) the SQL standard says what hex values should be translated to in > > binary, which implies that all values may be *output* in binary format. > So the standard says both represent a fixed-length bit string data type. > ISTM that we should not try to preserve any information on the units > used for input, and that both should be output in the same way. OK, that's how I read it too. I'll work on making it behave with hex input and not worry about the output, which takes care of itself. I also notice that the following has trouble: thomas=# select bit '1010'; ERROR: bit string length does not match type bit(1) which is similar to the very recent problem with fixed-length character strings. I've got patches to fix this one too. - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_views.definition
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > It's really annoying when people save their view definition in phpPgAdmin > and when they load it up again it's lost all formatting. Functions and > rules, for instance keep the original formatting somewhere. Rules do not. (A view is just a rule anyway.) Functions do, but that's because their definition is entered as a text string, which leads directly to those quoting headaches that you're all too familiar with. I've thought occasionally about improving the lexer so that parsetree nodes could be tagged with the section of the source text they were built from (probably in the form of a (start offset, end offset) pair). This was mainly for use in improving error reporting in the parse-analysis phase, but it might be useful for storing original source text for rules too. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] line datatype
Thomas Lockhart <[EMAIL PROTECTED]> writes: > The issue is in choosing an external format for LINE which does not lose > precision during dump/reload. Why is this any worse for LINE than for any of the other geometric types (or for plain floats, for that matter)? We do need a solution for exact dump/reload of floating-point data, but I don't see why the lack of it should be reason to disable access to the LINE type. 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: [HACKERS] pg_views.definition
Bruce Momjian wrote: > > Christopher Kings-Lynne wrote: > > Hi, > > > > Would it be possible to add a new attribute to pg_views that stores the > > original view definition, as entered via SQL? > > > > This would make the lives of those of us who make admin interfaces a lot > > easier... > > We actually reverse it on the fly: We do, but as soon as you break the view by dropping an underlying object it fails to reconstruct. So having the original view definition at hand could be useful for some ALTER VIEW RECOMPILE command. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] line datatype
Tom Lane wrote: > Thomas Lockhart <[EMAIL PROTECTED]> writes: > > The issue is in choosing an external format for LINE which does not lose > > precision during dump/reload. > > Why is this any worse for LINE than for any of the other geometric > types (or for plain floats, for that matter)? > > We do need a solution for exact dump/reload of floating-point data, > but I don't see why the lack of it should be reason to disable access > to the LINE type. I don't understand why dumping the two point values isn't sufficient. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] line datatype
... > > We do need a solution for exact dump/reload of floating-point data, > > but I don't see why the lack of it should be reason to disable access > > to the LINE type. > I don't understand why dumping the two point values isn't sufficient. Which two point values? LINE is handled as an equation, not as points, unlike the LSEG type which has two points. One possibility is to have the external representation *be* the same as LSEG, then convert internally. Then we need to decide how to scale those points; maybe always using a unit vector is the right thing to do... - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SQL] line datatype
Thomas Lockhart wrote: > ... > > > We do need a solution for exact dump/reload of floating-point data, > > > but I don't see why the lack of it should be reason to disable access > > > to the LINE type. > > I don't understand why dumping the two point values isn't sufficient. > > Which two point values? LINE is handled as an equation, not as points, > unlike the LSEG type which has two points. Well, the \dT documentation used to show line as two points, so I assumed that was how it was specified. > One possibility is to have the external representation *be* the same as > LSEG, then convert internally. Then we need to decide how to scale those > points; maybe always using a unit vector is the right thing to do... No one likes entering an equation. Two points seems the simplest. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] [PATCHES] CLUSTER not lose indexes
Curt Sampson wrote: > On Mon, 15 Jul 2002, Bruce Momjian wrote: > > > > (In related news, how about filling up the oid/relfilenode numbers with > > > zeros on the left, so a directory listing would reflect the numerical > > > order?) > > > > Problem there is that we increase the size of much of the directory > > lookups. Not sure if it is worth worrying about. > > Probably not such a big deal, since most systems will be reading > a full block (8K or 16K under *BSD) to load the directory information > anyway. Doing it in hex would give you only 8-char filenames, anyway. Yes, hex may be interesting as a more compact, consistent format. We need to change the docs so oid2name and queries convert to hex on output. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
Bruce Momjian <[EMAIL PROTECTED]> writes: >> (In related news, how about filling up the oid/relfilenode numbers with >> zeros on the left, so a directory listing would reflect the numerical >> order?) > Yes, hex may be interesting as a more compact, consistent format. We > need to change the docs so oid2name and queries convert to hex on > output. I don't really see the value-added here. If we had made this decision before releasing 7.1, I'd not have objected; but at this point we're talking about breaking oid2name and any similar scripts that people may have developed, for what's really a *very* marginal gain. Who cares whether a directory listing reflects numerical order? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> (In related news, how about filling up the oid/relfilenode numbers with > >> zeros on the left, so a directory listing would reflect the numerical > >> order?) > > > Yes, hex may be interesting as a more compact, consistent format. We > > need to change the docs so oid2name and queries convert to hex on > > output. > > I don't really see the value-added here. If we had made this decision > before releasing 7.1, I'd not have objected; but at this point we're > talking about breaking oid2name and any similar scripts that people > may have developed, for what's really a *very* marginal gain. Who cares > whether a directory listing reflects numerical order? I don't see the big value either, just brainstorming. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] line datatype
Actually... as one with the vested interest... I'm not opposed to entering an equation in one of the basic algebraic forms. Given that line types and line segment types both exist, I'm happy to weigh the cost/benefit between choosing an lseg and entering 2 points, or choosing a line and entering the equation. Are there database functions to translate between a line and a line seg? If so, that would address my only reservation for restricting the line type to an equation. And - to address Tom's continuing concern over casting ;), I have no need for implicit casts in this case. If there are concerns about precision being lost in the translation - As long as what precision can be guaranteed is documented, I have no qualms. If I needed absolute precision I'd create my own line table with numerics, and write my own functions as necessary. The line type to me is there for speed and ease of use, not unlimited precision. On Tuesday, 16, 2002, at 09:38AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: >No one likes entering an equation. Two points seems the simplest. > >-- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_views.definition
Jan Wieck <[EMAIL PROTECTED]> writes: >> We actually reverse it on the fly: > We do, but as soon as you break the view by dropping an underlying > object it fails to reconstruct. So having the original view definition > at hand could be useful for some ALTER VIEW RECOMPILE command. Note that the assumptions underlying this discussion have changed in CVS tip: you can't break a view by dropping underlying objects. regression=# create table foo(f1 int, f2 text); CREATE TABLE regression=# create view bar as select * from foo; CREATE VIEW regression=# drop table foo; NOTICE: rule _RETURN on view bar depends on table foo NOTICE: view bar depends on rule _RETURN on view bar ERROR: Cannot drop table foo because other objects depend on it Use DROP ... CASCADE to drop the dependent objects too or regression=# drop table foo cascade; NOTICE: Drop cascades to rule _RETURN on view bar NOTICE: Drop cascades to view bar DROP TABLE -- bar is now gone Auto reconstruction of a view based on its original textual definition is still potentially interesting, but I submit that it won't necessarily always give the right answer. 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] [SQL] line datatype
... > Well, the \dT documentation used to show line as two points, so I > assumed that was how it was specified. Hmm. And it seems I entered it a few years ago ;) Cut and paste error. At that time the line type was defined but has never had the i/o routines enabled. > No one likes entering an equation. Two points seems the simplest. That it does. - Thomas ---(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] [SQL] line datatype
On Tuesday 16 July 2002 11:29 am, Thomas Lockhart wrote: > > > We do need a solution for exact dump/reload of floating-point data, > > > but I don't see why the lack of it should be reason to disable access > > > to the LINE type. > > I don't understand why dumping the two point values isn't sufficient. > Which two point values? LINE is handled as an equation, not as points, > unlike the LSEG type which has two points. > One possibility is to have the external representation *be* the same as > LSEG, then convert internally. Then we need to decide how to scale those > points; maybe always using a unit vector is the right thing to do... Lines are entered now by specifying two points, anywhere on the line, right? The internal representation is then slope-intercept? Why not allow either the 'two-point' entry, or direct entry as slope-intercept? How do we represent lines now in output? Do we pick two arbitrary points on the line? If so, I can see Thomas' point here, where the original data entry might have specified two relatively distant points -- but then there's a precision error anyway converting to slope-intercept, if indeed that is the internal representation. So why not dump in slope-intercept form, if that is the internal representation? But, you're telling me floats aren't dumpable/restoreable to exactly the same value? () This can't be good. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] DROP COLUMN
> -Original Message- > From: Bruce Momjian > > Christopher Kings-Lynne wrote: > > > Uh, then what? The only idea I had was to set a static boolean > > > variable in > > > syscache.c that controls whether droppped columns are > returned, and have > > > a enable/disable functions that can turn it on/off. The only > problem is > > > that an elog inside a syscache lookup would leave that value set. > > > > > > My only other idea is to make a syscache that is like ATTNAME except > > > that it doesn't return a dropped column. I could probably > code that up > > > if you wish. > > > > That'd be cool. > > > > I guess the thing is that either way, I will need to manually > change every > > single instance where a dropped column should be avoided. So, really > > there's not much difference between me changing the SysCache > search to use > > ATTNAMEUNDROPPED or whatever, or just checking the attisdropped > field of the > > tuple in the same way that you must always check that attnum > 0. > > > > In fact, looking at it logically...if all the commands currently are > > required to check that they're not modifiying a system column, > then why not > > add the requirement that they must also not modify dropped > columns? I can > > do a careful doc search and try to make sure I've touched everything... > > Makes sense. Of course, we could make a syscache that didn't return > system columns either. > > Actually, the original argument for negative attno's for dropped columns > was exactly for this case, that the system column check would catch > dropped columns too, > but it causes other problems that are harder to fix > so we _dropped_ the idea. What does this mean ? BTW would we do nothing for clients after all ? regards, Hiroshi Inoue ---(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
[HACKERS] OID suppression issues
I've been thinking that it's really not a good idea to make the OID field optional without any indication in the tuple header whether it is present. In particular, this will make life difficult for tools like pg_filedump that try to display tuple headers without any outside information. I think it'd be a good idea to expend a bit in t_infomask to show whether an OID field is allocated or not. We currently have two free bits in t_infomask, which is starting to get a bit tight, but offhand I do not see anything else coming down the pike that would need another bit. Also, we could consider expanding t_infomask to three bytes if we had to. Comments? 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] [SQL] line datatype
Lamar Owen wrote: > On Tuesday 16 July 2002 11:29 am, Thomas Lockhart wrote: > > > > We do need a solution for exact dump/reload of floating-point data, > > > > but I don't see why the lack of it should be reason to disable access > > > > to the LINE type. > > > > I don't understand why dumping the two point values isn't sufficient. > > > Which two point values? LINE is handled as an equation, not as points, > > unlike the LSEG type which has two points. > > > One possibility is to have the external representation *be* the same as > > LSEG, then convert internally. Then we need to decide how to scale those > > points; maybe always using a unit vector is the right thing to do... > > Lines are entered now by specifying two points, anywhere on the line, right? > The internal representation is then slope-intercept? Why not allow either > the 'two-point' entry, or direct entry as slope-intercept? How do we > represent lines now in output? Do we pick two arbitrary points on the line? > If so, I can see Thomas' point here, where the original data entry might have > specified two relatively distant points -- but then there's a precision error > anyway converting to slope-intercept, if indeed that is the internal > representation. So why not dump in slope-intercept form, if that is the > internal representation? Yow, I can see the pain of having slope/intercept and trying to output two points. What if we store line internally as two points, and convert to slope/intercept when needed. That way, it would dump out just as it was entered. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] DROP COLUMN
Hiroshi Inoue wrote: > > Makes sense. Of course, we could make a syscache that didn't return > > system columns either. > > > > Actually, the original argument for negative attno's for dropped columns > > was exactly for this case, that the system column check would catch > > dropped columns too, > > > but it causes other problems that are harder to fix > > so we _dropped_ the idea. > > What does this mean ? Client programmers prefered the dropped flag rather than negative attno's so we went with that. > BTW would we do nothing for clients after all ? Clients will now need to check that dropped flag. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] line datatype
Thomas Lockhart <[EMAIL PROTECTED]> writes: >> No one likes entering an equation. Two points seems the simplest. > That it does. On the other hand, if you want to enter two points why don't you just use lseg to begin with? There's not much justification for having a separate line type unless it behaves differently ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] line datatype
Tom Lane wrote: > Thomas Lockhart <[EMAIL PROTECTED]> writes: > >> No one likes entering an equation. Two points seems the simplest. > > > That it does. > > On the other hand, if you want to enter two points why don't you just > use lseg to begin with? There's not much justification for having a > separate line type unless it behaves differently ... I assume the line type keeps going after the two end points, while lseg doesn't. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_views.definition
Tom Lane wrote: > Auto reconstruction of a view based on its original textual definition > is still potentially interesting, but I submit that it won't necessarily > always give the right answer. Sure, it's another bullet to shoot yourself into someone elses foot. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [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_views.definition
Jan Wieck wrote: > Tom Lane wrote: > > Auto reconstruction of a view based on its original textual definition > > is still potentially interesting, but I submit that it won't necessarily > > always give the right answer. > > Sure, it's another bullet to shoot yourself into someone elses foot. Do we want this on TODO? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] DROP COLUMN
On Tue, 2002-07-16 at 18:30, Bruce Momjian wrote: > Hiroshi Inoue wrote: > > > Makes sense. Of course, we could make a syscache that didn't return > > > system columns either. > > > > > > Actually, the original argument for negative attno's for dropped columns > > > was exactly for this case, that the system column check would catch > > > dropped columns too, > > > > > but it causes other problems that are harder to fix > > > so we _dropped_ the idea. > > > > What does this mean ? > > Client programmers prefered the dropped flag rather than negative > attno's so we went with that. While you are at it,could you add another flag is_system ? --- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Spec on pg_cast table/CREATE CAST command
Command syntax is CREATE CAST (source AS target) WITH FUNCTION name(arg) [AS ASSIGNMENT] in compliance with SQL99 (AS ASSIGNMENT means implicitly invokable). Declaration of binary compatible casts: CREATE CAST (source AS target) WITHOUT FUNCTION [AS ASSIGNMENT] Does not have to be implicit (although it must be for use in function argument resultion, etc.). You must declare both directions explicitly. Cast functions must be immutable. This is following SQL99 as well. Compatibility: The old way to create casts has already been broken in 1.5 ways: the introduction of the implicit flag and the introduction of schemas. To maintain full compatibility we'd have to revert to making the implicit flag the default, which would undermine the compliance of the new CREATE CAST command from the start. Hence I suggest that we migrate through pg_dump: User-defined functions that would have been casts up to 7.2 will emit an appropriate CREATE CAST command. This in combination with a release note will also give the users a better chance to inspect the dump and adjust the cast specifications for implicitness as they wish. Comments? -- 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] BlockNumber fixes
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The only other
> > unusual case I saw was tid outputing block number as %d and not %u. Is
> > that OK?
>
> Seems like it should use %u. The input side might be wrong too.
>
OK, fixed. Patch attached. There was also some confusion in the code
of how strtol returns its end pointer as always non-NULL:
test=> insert into x values ('(1,2)');
INSERT 16591 1
test=> insert into x values ('(10,2)');
INSERT 16592 1
test=> insert into x values ('(30,2)');
INSERT 16593 1
test=> select * from x;
y
(1,2)
(10,2)
(30,2)
(3 rows)
test=> insert into x values ('(50,2)');
ERROR: tidin: invalid value.
test=> insert into x values ('(30,20)');
ERROR: tidin: invalid value.
test=> insert into x values ('(30,2)');
INSERT 16595 1
> > Also, pg_class.relpages is an int. We don't have unsigned int columns.
>
> Yeah. I had a todo item to look at all the uses of relpages and make
> sure they were being casted to unsigned ...
They all look OK to me.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Index: src/backend/utils/adt/numutils.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/numutils.c,v
retrieving revision 1.49
diff -c -r1.49 numutils.c
*** src/backend/utils/adt/numutils.c20 Jun 2002 20:29:38 - 1.49
--- src/backend/utils/adt/numutils.c16 Jul 2002 17:51:06 -
***
*** 46,52
pg_atoi(char *s, int size, int c)
{
longl = 0;
! char *badp = (char *) NULL;
Assert(s);
--- 46,52
pg_atoi(char *s, int size, int c)
{
longl = 0;
! char *badp;
Assert(s);
***
*** 71,77
*/
if (errno && errno != EINVAL)
elog(ERROR, "pg_atoi: error reading \"%s\": %m", s);
! if (badp && *badp && (*badp != c))
elog(ERROR, "pg_atoi: error in \"%s\": can\'t parse \"%s\"", s, badp);
switch (size)
--- 71,77
*/
if (errno && errno != EINVAL)
elog(ERROR, "pg_atoi: error reading \"%s\": %m", s);
! if (*badp && *badp != c)
elog(ERROR, "pg_atoi: error in \"%s\": can\'t parse \"%s\"", s, badp);
switch (size)
Index: src/backend/utils/adt/tid.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/tid.c,v
retrieving revision 1.31
diff -c -r1.31 tid.c
*** src/backend/utils/adt/tid.c 20 Jun 2002 20:29:38 - 1.31
--- src/backend/utils/adt/tid.c 16 Jul 2002 17:51:06 -
***
*** 18,23
--- 18,27
#include "postgres.h"
+ #include
+ #include
+ #include
+
#include "access/heapam.h"
#include "catalog/namespace.h"
#include "utils/builtins.h"
***
*** 47,52
--- 51,58
ItemPointer result;
BlockNumber blockNumber;
OffsetNumber offsetNumber;
+ char *badp;
+ int hold_offset;
for (i = 0, p = str; *p && i < NTIDARGS && *p != RDELIM; p++)
if (*p == DELIM || (*p == LDELIM && !i))
***
*** 55,62
if (i < NTIDARGS)
elog(ERROR, "invalid tid format: '%s'", str);
! blockNumber = (BlockNumber) atoi(coord[0]);
! offsetNumber = (OffsetNumber) atoi(coord[1]);
result = (ItemPointer) palloc(sizeof(ItemPointerData));
--- 61,76
if (i < NTIDARGS)
elog(ERROR, "invalid tid format: '%s'", str);
! errno = 0;
! blockNumber = strtoul(coord[0], &badp, 10);
! if (errno || *badp != DELIM)
! elog(ERROR, "tidin: invalid value.");
!
! hold_offset = strtol(coord[1], &badp, 10);
! if (errno || *badp != RDELIM ||
! hold_offset > USHRT_MAX || hold_offset < 0)
! elog(ERROR, "tidin: invalid value.");
! offsetNumber = hold_offset;
result = (ItemPointer) palloc(sizeof(ItemPointerData));
***
*** 87,93
blockNumber = BlockIdGetBlockNumber(blockId);
offsetNumber = itemPtr->ip_posid;
! sprintf(buf, "(%d,%d)", (int) blockNumber, (int) offsetNumber);
PG_RETURN_CSTRING(pstrdup(buf));
}
--- 101,107
blockNumber = BlockIdGetBlockNumber(blockId);
offsetNumber = itemPtr->ip_posid;
! sprintf(buf, "(%u,%u)", blockNumber, offsetNumber);
[HACKERS] Building PostgreSQL 7.2.1 w/ Tcl/Tk support on Mac OS X
So being very new with this code, I'd just like to get a feel for whether what I am seeing is consistent with what others have seen when they have attempted to build on Mac OS X 10.1.x. I built Tcl and Tk 8.4b1, and then PostgreSQL with Tcl support enabled. When PostgreSQL builds it reports the below fatal link error. I believe Tk yielded some warnings, but like an idiot I overwrote the log file instead of appending so I am now rebuilding Tk to find out what the warnings are. Unfortunately that takes about 3 hours, so I thought I'd at least get this out here. If this is at least similar to what others have seen, I'll begin tracking it down. Feel free to take this offline if you like. Thanks, Mike Ditto gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations pgtclAppInit.o -L../../../src/interfaces/libpgtcl -lpgtcl -L../../../src/interfaces/libpq -lpq -L/sw/lib -lz -ldl -lm -o pgtclsh /usr/bin/ld: Undefined symbols: _Tcl_Init _Tcl_Main _Tcl_SetVar _Tcl_CreateCommand _Tcl_CreateObjCommand _Tcl_GetDouble _Tcl_GetVar _Tcl_PkgProvide _Tcl_AddErrorInfo _Tcl_Alloc _Tcl_AppendElement _Tcl_AppendResult _Tcl_CallWhenDeleted _Tcl_DStringAppendElement _Tcl_DStringEndSublist _Tcl_DStringFree _Tcl_DStringInit _Tcl_DStringResult _Tcl_DStringStartSublist _Tcl_DeleteHashEntry _Tcl_Eval _Tcl_Free _Tcl_GetChannel _Tcl_GetIntFromObj _Tcl_GetStringFromObj _Tcl_InitHashTable _Tcl_NewIntObj _Tcl_NewStringObj _Tcl_ObjSetVar2 _Tcl_ResetResult _Tcl_SetObjResult _Tcl_SetResult _Tcl_SetVar2 _Tcl_UnregisterChannel _Tcl_UnsetVar _Tcl_BackgroundError _Tcl_CreateChannel _Tcl_CreateChannelHandler _Tcl_DeleteChannelHandler _Tcl_DeleteEvents _Tcl_DeleteHashTable _Tcl_DontCallWhenDeleted _Tcl_EventuallyFree _Tcl_FirstHashEntry _Tcl_GetChannelInstanceData _Tcl_GetChannelName _Tcl_GetChannelType _Tcl_GetInt _Tcl_GlobalEval _Tcl_MakeTcpClientChannel _Tcl_NextHashEntry _Tcl_Preserve _Tcl_QueueEvent _Tcl_Realloc _Tcl_RegisterChannel _Tcl_Release _Tcl_SetChannelOption gnumake[3]: *** [pgtclsh] Error 1 gnumake[2]: *** [all] Error 2 gnumake[1]: *** [all] Error 2 gnumake: *** [all] Error 2 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Spec on pg_cast table/CREATE CAST command
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Command syntax is > CREATE CAST (source AS target) WITH FUNCTION name(arg) [AS ASSIGNMENT] > in compliance with SQL99 (AS ASSIGNMENT means implicitly invokable). > Declaration of binary compatible casts: > CREATE CAST (source AS target) WITHOUT FUNCTION [AS ASSIGNMENT] So the idea is to remove proimplicit again? We could still do that before 7.3, since no user depends on it yet. Are you intending a new system catalog to hold casts? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)
J.R., just checking to see how PITR recovery is going. Do you need any assistance or have any questions for us? Also, do you have any idea how close you are to having something completed? Are you aware we are closing development of 7.3 at the end of August and start beta September 1? Is there any way we can help you? --- J. R. Nield wrote: > On Fri, 2002-07-05 at 01:42, Bruce Momjian wrote: > > > > We have needed > > point-in-time recovery for a long time, > > Most thanks should go to vadim (and whoever else worked on this), since > his WAL code already does most of the work. The key thing is auditing > the backend to look for every case where we assume some action is not > visible until after commit, and therefore don't log its effects. Those > are the main cases that must be changed. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Do we still need these NOTICEs?
I am considering removing the following notices/warnings, since they seem to be unnecessary in the brave new world of dependencies: * The one about dropping a built-in function; you can't do it anyway. regression=# drop function now(); WARNING: Removing built-in function "now" ERROR: Cannot drop function now because it is required by the database system regression=# * The one about creating implicit triggers for FOREIGN KEY constraints: regression=# create table bar (f1 int references foo); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) CREATE TABLE regression=# Since those triggers (a) will be auto-dropped when you drop the constraint, and (b) can't be dropped without dropping the constraint, this notice seems like it's just noise now. regression=# \d bar Table "bar" Column | Type | Modifiers +-+--- f1 | integer | Triggers: RI_ConstraintTrigger_140127 regression=# drop trigger "RI_ConstraintTrigger_140127" on bar; ERROR: Cannot drop trigger RI_ConstraintTrigger_140127 on table bar because constraint $1 on table bar requires it You may drop constraint $1 on table bar instead regression=# alter table bar drop constraint "$1"; ALTER TABLE regression=# \d bar Table "bar" Column | Type | Modifiers +-+--- f1 | integer | regression=# * The ones about implicit indexes for primary key/unique constraints and about implicit sequences for SERIAL columns also seem unnecessary now --- as with the trigger case, you can't drop the implicit object directly anymore. However, the messages do convey some useful information, namely the exact name that was assigned to the index or sequence. So I'm undecided about removing 'em. The sequence message seems particularly useful since people do often want to refer directly to the sequence in manual nextval/currval commands. OTOH psql's \d is a perfectly reasonable way to get the sequence and index names if you need 'em. Moreover, that still works after the fact whereas a NOTICE soon disappears from sight. Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SQL] line datatype
> >> No one likes entering an equation. Two points seems the simplest. > > That it does. > On the other hand, if you want to enter two points why don't you just > use lseg to begin with? There's not much justification for having a > separate line type unless it behaves differently ... They are different. One is infinite in length, the other is finite. Distances, etc are calculated differently between the two types. - Thomas ---(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] [SQL] line datatype
On Tuesday 16 July 2002 04:42 pm, Thomas Lockhart wrote: > > On the other hand, if you want to enter two points why don't you just > > use lseg to begin with? There's not much justification for having a > > separate line type unless it behaves differently ... > They are different. One is infinite in length, the other is finite. > Distances, etc are calculated differently between the two types. For some of my work a type of 'ray' would be nice... :-) But LSEG's usually work OK as long as you specify an endpoint that is far enough away. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] getopt_long search in configure
Bruce Momjian writes: > I have it here in /usr/local/include. Not sure how it got there. It > must have been installed by some other software. OK good. But the check should be AC_SEARCH_LIBS(getopt_long, [getopt]) That way you check if the library actually contains the function you want. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Future of src/utils
Bruce Momjian writes: > Yea, I thought of that. Means all the subdirectores have to move too. > It is more extreme than moving stuff from /src/utils, but it is more > logical. I don't think we need to move the subdirectories, which involve stuff that's heavily tied to the backend. But the generic C library replacement files should move into src/utils preferably. In fact, what we could do is assemble all the files we need (as determined by configure) into a static library and link all executables with that. That way we don't have to deal with the individual files in each individual makefile. -- Peter Eisentraut [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] bit type external representation
Thomas Lockhart writes: > SQL9x defines bit string constants with a format like > > B'101010' > and > X'ABCD' > > for binary and hexadecimal representations. But at the moment we don't > explicitly handle both of these cases as bit strings; the hex version is > converted to decimal in the scanner (*really* early in the parsing > stage) and then handled as an integer. The sole reason that this is still unresolved is that the SQL standard is ambiguous about whether a literal of the form X'something' is of type bit () or of type blob (). If I had to choose one, I'd actually lean toward blob (or bytea in our case). Two ideas: 1. make an "unknownhex" type and resolve it late, like the "unknown" type. 2. allow an implicit cast from bytea to bit. > It looks like our current bit string type support looks for a "B" or "X" > embedded in the actual input string, rather than outside the quote as in > the standard. This was a stopgap measure before the B'' syntax was implemented. I guess it's grown to be a feature now. :-/ > 1) the SQL standard says what hex values should be translated to in > binary, which implies that all values may be *output* in binary format. > Should we do this, or should we preserve the info on what units were > used for input in the internal storage? Anyone interpret the standard > differently from this?? I believe you are caught in the confusion I was referring to above: hex values are possibly not even of type bit at all. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Future of src/utils
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I don't think we need to move the subdirectories, which involve stuff > that's heavily tied to the backend. But the generic C library replacement > files should move into src/utils preferably. In fact, what we could do is > assemble all the files we need (as determined by configure) into a static > library and link all executables with that. That way we don't have to > deal with the individual files in each individual makefile. I like that a lot. But will it work for libpq? I have a feeling we'd end up linking *all* the replacement functions into libpq, which might create some namespace issues for client applications. Ideally we should only link the functions libpq actually needs into libpq, but I'm not sure that works with standard linker behavior. 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: [HACKERS] DROP COLUMN
Bruce Momjian wrote: > > Hiroshi Inoue wrote: > > > Makes sense. Of course, we could make a syscache that didn't return > > > system columns either. > > > > > > Actually, the original argument for negative attno's for dropped columns > > > was exactly for this case, that the system column check would catch > > > dropped columns too, > > > > > but it causes other problems that are harder to fix > > > so we _dropped_ the idea. > > > > What does this mean ? > > Client programmers prefered the dropped flag rather than negative > attno's so we went with that. What I asked you is what *harder to fix* means. > > BTW would we do nothing for clients after all ? > > Clients will now need to check that dropped flag. Clients would have to check the flag everywhere pg_attribute appears. Why should clients do such a thing ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_views.definition
> > We do, but as soon as you break the view by dropping an underlying > > object it fails to reconstruct. So having the original view definition > > at hand could be useful for some ALTER VIEW RECOMPILE command. > > Note that the assumptions underlying this discussion have changed in > CVS tip: you can't break a view by dropping underlying objects. > > regression=# create table foo(f1 int, f2 text); > CREATE TABLE > regression=# create view bar as select * from foo; > CREATE VIEW > regression=# drop table foo; > NOTICE: rule _RETURN on view bar depends on table foo > NOTICE: view bar depends on rule _RETURN on view bar > ERROR: Cannot drop table foo because other objects depend on it > Use DROP ... CASCADE to drop the dependent objects too Hrm - looks like we really need CREATE OR REPLACE VIEW... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Do we still need these NOTICEs?
> * The one about dropping a built-in function; you can't do it anyway. > > regression=# drop function now(); > WARNING: Removing built-in function "now" > ERROR: Cannot drop function now because it is required by the > database system > regression=# Get rid of it. > * The one about creating implicit triggers for FOREIGN KEY constraints: > > regression=# create table bar (f1 int references foo); > NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN > KEY check(s) > CREATE TABLE > regression=# > > Since those triggers (a) will be auto-dropped when you drop the > constraint, and (b) can't be dropped without dropping the constraint, > this notice seems like it's just noise now. Yep - may as well. > regression=# \d bar > Table "bar" > Column | Type | Modifiers > +-+--- > f1 | integer | > Triggers: RI_ConstraintTrigger_140127 > > regression=# drop trigger "RI_ConstraintTrigger_140127" on bar; > ERROR: Cannot drop trigger RI_ConstraintTrigger_140127 on table > bar because constraint $1 on table bar requires it > You may drop constraint $1 on table bar instead > regression=# alter table bar drop constraint "$1"; > ALTER TABLE > regression=# \d bar > Table "bar" > Column | Type | Modifiers > +-+--- > f1 | integer | > > regression=# > > * The ones about implicit indexes for primary key/unique constraints > and about implicit sequences for SERIAL columns also seem unnecessary > now --- as with the trigger case, you can't drop the implicit object > directly anymore. However, the messages do convey some useful > information, namely the exact name that was assigned to the index or > sequence. So I'm undecided about removing 'em. The sequence message > seems particularly useful since people do often want to refer directly > to the sequence in manual nextval/currval commands. OTOH psql's \d is a > perfectly reasonable way to get the sequence and index names if you need > 'em. Moreover, that still works after the fact whereas a NOTICE soon > disappears from sight. H...undecided. I generally wouldn't care I guess, but some people might... Chris ---(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] pg_views.definition
On Wed, 17 Jul 2002, Christopher Kings-Lynne wrote: > > > We do, but as soon as you break the view by dropping an underlying > > > object it fails to reconstruct. So having the original view definition > > > at hand could be useful for some ALTER VIEW RECOMPILE command. > > > > Note that the assumptions underlying this discussion have changed in > > CVS tip: you can't break a view by dropping underlying objects. > > > > regression=# create table foo(f1 int, f2 text); > > CREATE TABLE > > regression=# create view bar as select * from foo; > > CREATE VIEW > > regression=# drop table foo; > > NOTICE: rule _RETURN on view bar depends on table foo > > NOTICE: view bar depends on rule _RETURN on view bar > > ERROR: Cannot drop table foo because other objects depend on it > > Use DROP ... CASCADE to drop the dependent objects too > > Hrm - looks like we really need CREATE OR REPLACE VIEW... I have written a patch for this. It is in an old source tree. I intend on getting it together by august, along with create or replace trigger. Gavin ---(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] pg_views.definition
> > Hrm - looks like we really need CREATE OR REPLACE VIEW... > > I have written a patch for this. It is in an old source tree. I intend on > getting it together by august, along with create or replace trigger. Sweet. I was going to email to see if you had a copy of your old create or replace function patch that I could convert. (Just as soon as this drop column stuff is done.) Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Future of src/utils
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > I don't think we need to move the subdirectories, which involve stuff > > that's heavily tied to the backend. But the generic C library replacement > > files should move into src/utils preferably. In fact, what we could do is > > assemble all the files we need (as determined by configure) into a static > > library and link all executables with that. That way we don't have to > > deal with the individual files in each individual makefile. > > I like that a lot. But will it work for libpq? I have a feeling we'd Yes, I like it too, and I like the fact that the subdirectories stay, because those are so backend-specific, it doesn't make any sense to move them. Can we move them to src/port rather than src/utils? Port makes more sense to me because that's what they are. Maybe is should be called src/libc? > end up linking *all* the replacement functions into libpq, which might > create some namespace issues for client applications. Ideally we should > only link the functions libpq actually needs into libpq, but I'm not > sure that works with standard linker behavior. Linkers work per object file, so if each member of the library has only one function in it (which is how we do it now anyway) a linker will pick out only the object files it needs. Many C libraries have multiple functions per object file, and that's where you see the namespace pollution. Actually, our current setup is more prone to pollution becuse we unconditionally add *.o files to the link line. Add a library makes sure only the object files needed are added to the executable. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] getopt_long search in configure
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I have it here in /usr/local/include. Not sure how it got there. It > > must have been installed by some other software. > > OK good. But the check should be > > AC_SEARCH_LIBS(getopt_long, [getopt]) > > That way you check if the library actually contains the function you want. Thanks. Change made. I was finding it hard to debug the pg_restore flag problems without long options. This way, I have them. I will try to research how I got libgetopt.a in /usr/local/include. Does anyone else have one? Maybe I generated it by hand. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_views.definition
Christopher Kings-Lynne wrote: >>>We do, but as soon as you break the view by dropping an underlying >>>object it fails to reconstruct. So having the original view definition >>>at hand could be useful for some ALTER VIEW RECOMPILE command. >> >>Note that the assumptions underlying this discussion have changed in >>CVS tip: you can't break a view by dropping underlying objects. >> >>regression=# create table foo(f1 int, f2 text); >>CREATE TABLE >>regression=# create view bar as select * from foo; >>CREATE VIEW >>regression=# drop table foo; >>NOTICE: rule _RETURN on view bar depends on table foo >>NOTICE: view bar depends on rule _RETURN on view bar >>ERROR: Cannot drop table foo because other objects depend on it >>Use DROP ... CASCADE to drop the dependent objects too > > > Hrm - looks like we really need CREATE OR REPLACE VIEW... The problem is that you would still need to keep a copy of your view around to recreate it if you wanted to drop and recreate a table it depends on. I really like the idea about keeping the original view source handy in the system catalogs. It is common in Oracle to have dependent objects like views and packages get invalidated when something they depend on is dropped/recreated. Would it make sense to do something like that? I.e. set a relisvalid flag to false, and generate an ERROR telling you to recompile the object if you try to use it while invalid. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Do we still need these NOTICEs?
Tom Lane wrote: > I am considering removing the following notices/warnings, since they > seem to be unnecessary in the brave new world of dependencies: > > * The one about dropping a built-in function; you can't do it anyway. > > regression=# drop function now(); > WARNING: Removing built-in function "now" > ERROR: Cannot drop function now because it is required by the database system > regression=# > > * The one about creating implicit triggers for FOREIGN KEY constraints: Yep, remove them. > regression=# create table bar (f1 int references foo); > NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) > CREATE TABLE > regression=# > > Since those triggers (a) will be auto-dropped when you drop the > constraint, and (b) can't be dropped without dropping the constraint, > this notice seems like it's just noise now. > > regression=# \d bar > Table "bar" > Column | Type | Modifiers > +-+--- > f1 | integer | > Triggers: RI_ConstraintTrigger_140127 > > regression=# drop trigger "RI_ConstraintTrigger_140127" on bar; > ERROR: Cannot drop trigger RI_ConstraintTrigger_140127 on table bar because >constraint $1 on table bar requires it > You may drop constraint $1 on table bar instead > regression=# alter table bar drop constraint "$1"; > ALTER TABLE > regression=# \d bar > Table "bar" > Column | Type | Modifiers > +-+--- > f1 | integer | > > regression=# Remove. > * The ones about implicit indexes for primary key/unique constraints > and about implicit sequences for SERIAL columns also seem unnecessary > now --- as with the trigger case, you can't drop the implicit object > directly anymore. However, the messages do convey some useful > information, namely the exact name that was assigned to the index or > sequence. So I'm undecided about removing 'em. The sequence message > seems particularly useful since people do often want to refer directly > to the sequence in manual nextval/currval commands. OTOH psql's \d is a > perfectly reasonable way to get the sequence and index names if you need > 'em. Moreover, that still works after the fact whereas a NOTICE soon > disappears from sight. I would remove them all. If people complain, we can add them back in. Why not remove them and keep the diff on your machine somewhere. If we get complaints, we can re-add them. We already get complaints about people _not_ wanting to see them, and hence the request to disable NOTICE messages in psql, which will be possible in 7.3. Now that we have them auto-dropped, it is appropriate for them not to appear during creation. We mentioned them in the past specifically so people would know they existed to drop them. Now, they don't need to know that anymore. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] DROP COLUMN
Hiroshi Inoue wrote: > Bruce Momjian wrote: > > > > Hiroshi Inoue wrote: > > > > Makes sense. Of course, we could make a syscache that didn't return > > > > system columns either. > > > > > > > > Actually, the original argument for negative attno's for dropped columns > > > > was exactly for this case, that the system column check would catch > > > > dropped columns too, > > > > > > > but it causes other problems that are harder to fix > > > > so we _dropped_ the idea. > > > > > > What does this mean ? > > > > Client programmers prefered the dropped flag rather than negative > > attno's so we went with that. > > What I asked you is what *harder to fix* means. Uh, some said that having attno's like 1,2,3,5,7,8,9 with gaps would cause coding problems in client applications, and that was easier to have the numbers as 1-9 and check a flag if the column is dropped. Why that is easier than having gaps, I don't understand. I voted for the gaps (with negative attno's) but client coders liked the flag, so we went with that. > > > BTW would we do nothing for clients after all ? > > > > Clients will now need to check that dropped flag. > > Clients would have to check the flag everywhere > pg_attribute appears. > Why should clients do such a thing ? Well, good question. They could easily skip the dropped columns if we used negative attno's because they usually already skip system columns. However, they prefered a specific dropped column flag and positive attno's. I don't know why. They would have to explain. >From my perspective, when client coders like Dave Page and others say they would prefer the flag to the negative attno's, I don't have to understand. I just take their word for it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Do we still need these NOTICEs?
Bruce Momjian wrote: > Tom Lane wrote: > >>I am considering removing the following notices/warnings, since they >>seem to be unnecessary in the brave new world of dependencies: I also agree with removing all of these. >>* The ones about implicit indexes for primary key/unique constraints >>and about implicit sequences for SERIAL columns also seem unnecessary >>now --- as with the trigger case, you can't drop the implicit object >>directly anymore. One thing I wondered about here -- is it still possible to use a sequence, which is autogenerated by a SERIAL column, as the default value for another table? If so, does this create another dependency to prevent dropping the sequence, and hence the original (creating) table also? Joe ---(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] Do we still need these NOTICEs?
Joe Conway wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > >>I am considering removing the following notices/warnings, since they > >>seem to be unnecessary in the brave new world of dependencies: > > I also agree with removing all of these. > > >>* The ones about implicit indexes for primary key/unique constraints > >>and about implicit sequences for SERIAL columns also seem unnecessary > >>now --- as with the trigger case, you can't drop the implicit object > >>directly anymore. > > One thing I wondered about here -- is it still possible to use a > sequence, which is autogenerated by a SERIAL column, as the default > value for another table? If so, does this create another dependency to > prevent dropping the sequence, and hence the original (creating) table also? My guess is that the dependency code will now track it(?). A harder issue is if you use nextval() in the INSERT, there is no way for the dependency code to know it is used by that table, so it will be dropped if the parent table that created it is dropped. In such cases, the sequence should always be created manually or a DEFAULT defined, even if you never use it as a default. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
Bruce Momjian <[EMAIL PROTECTED]> writes: >> What I asked you is what *harder to fix* means. > Uh, some said that having attno's like 1,2,3,5,7,8,9 with gaps would > cause coding problems in client applications, and that was easier to > have the numbers as 1-9 and check a flag if the column is dropped. Why > that is easier than having gaps, I don't understand. I voted for the > gaps (with negative attno's) but client coders liked the flag, so we > went with that. It seems to me that the problems Chris is noticing have to do with gaps in the sequence of valid (positive) attnums. I don't believe that the negative-attnum approach to marking deleted columns would make those issues any easier (or harder) to fix. Either way you have a gap. But since the historical convention is "negative attnum is a system column", and deleted columns are *not* system columns, I prefer the idea of using a separate marker for deleted columns. AFAICT the comments from application coders have also been that they don't want to confuse these two concepts. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP COLUMN
Bruce Momjian wrote: > > Hiroshi Inoue wrote: > > Bruce Momjian wrote: > > > > > > Hiroshi Inoue wrote: > > > > > BTW would we do nothing for clients after all ? > > > > > > Clients will now need to check that dropped flag. > > > > Clients would have to check the flag everywhere > > pg_attribute appears. > > Why should clients do such a thing ? > > Well, good question. They could easily skip the dropped columns if we > used negative attno's because they usually already skip system columns. > However, they prefered a specific dropped column flag and positive > attno's. I don't know why. They would have to explain. I don't stick to negative attno's but > >From my perspective, when client coders like Dave Page and others say > they would prefer the flag to the negative attno's, I don't have to > understand. I just take their word for it. do they really love to check attisdropped everywhere ? Isn't it the opposite of the encapsulation ? I don't understand why we would do nothing for clients. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Do we still need these NOTICEs?
Joe Conway <[EMAIL PROTECTED]> writes:
> One thing I wondered about here -- is it still possible to use a
> sequence, which is autogenerated by a SERIAL column, as the default
> value for another table?
Sure, same as before.
> If so, does this create another dependency to
> prevent dropping the sequence, and hence the original (creating) table also?
As the code stands, no. The other table's default would look like
nextval('first_table_col_seq')
and the dependency deducer only sees nextval() and a string constant
in this.
Someday I'd like to see us support the Oracle-ish syntax
first_table_col_seq.nextval
which would expose the sequence reference in a way that allows the
system to understand it during static examination of a query.
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] Issues Outstanding for Point In Time Recovery (PITR)
On Tue, 2002-07-16 at 15:36, Bruce Momjian wrote: > > J.R., just checking to see how PITR recovery is going. Do you need any > assistance or have any questions for us? > > Also, do you have any idea how close you are to having something > completed? Are you aware we are closing development of 7.3 at the end > of August and start beta September 1? Is there any way we can help you? > It should be ready to go into CVS by the end of the month. That will include: logging all operations except for rtree and GiST, archival of logfiles (with new postgresql.conf params), headers on the logfiles to verify the system that created them, standalone backend recovery to a point-in-time, and a rudimentary hot backup capability. I could use some advice on the proper way to add tests to configure.in, given that the autoconf output is in CVS. Would you ever want a patch to include the generated 'configure' file? Related to that, the other place I need advice is on adding Ted Tso's LGPL'd UUID library (stolen from e2fsprogs) to the source. Are we allowed to use this? There is a free OSF/DCE spec for UUID's, so I can re-implement the library if required. We also haven't discussed commands for backup/restore, but I will use what I think is appropriate and we can change the grammar if needed. The initial hot-backup capability will require the database to be in read-only mode and use tar for backup, and I will add the ability to allow writes later. Does this sound like a reasonable timeframe/feature-set to make the 7.3 release? -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DROP COLUMN
Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> What I asked you is what *harder to fix* means. > > > Uh, some said that having attno's like 1,2,3,5,7,8,9 with gaps would > > cause coding problems in client applications, and that was easier to > > have the numbers as 1-9 and check a flag if the column is dropped. Why > > that is easier than having gaps, I don't understand. I voted for the > > gaps (with negative attno's) but client coders liked the flag, so we > > went with that. > > It seems to me that the problems Chris is noticing have to do with > gaps in the sequence of valid (positive) attnums. I don't believe that > the negative-attnum approach to marking deleted columns would make those > issues any easier (or harder) to fix. Either way you have a gap. Have I ever mentioned that negative attno's is better than the attisdropped flag implemetation in the handling of gaps in attnums ? And I don't object to the attisdropped flag implemetation as long as it doesn't scatter the attisdropped test around client applications. Why would you like to do nothing for clients ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(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] DROP COLUMN
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Have I ever mentioned that negative attno's is better > than the attisdropped flag implemetation in the handling > of gaps in attnums ? How so? I don't see any improvement ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)
"J. R. Nield" <[EMAIL PROTECTED]> writes: > Related to that, the other place I need advice is on adding Ted Tso's > LGPL'd UUID library (stolen from e2fsprogs) to the source. Are we > allowed to use this? Uh, why exactly is UUID essential for this? (The correct answer is "it's not", IMHO.) > We also haven't discussed commands for backup/restore, but I will use > what I think is appropriate and we can change the grammar if needed. The > initial hot-backup capability will require the database to be in > read-only mode and use tar for backup, and I will add the ability to > allow writes later. There is no read-only mode, and I for one will resist adding one. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DROP COLUMN
Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > Have I ever mentioned that negative attno's is better > > than the attisdropped flag implemetation in the handling > > of gaps in attnums ? > > How so? I don't see any improvement ... Sorry please ignore my above words if it has no meanig to you. My comments about this item always seem to be misunderstood. I've never intended to persist that my trial work using negative attno's was better than the attisdropped implementa- tion. I've only intended to guard my work from being evaluated unfairly. In my feeling you evaluated my work unfairly without any verfication twice. I've protected againast you about it each time but never got your explicit reply. Or have I missed your reply ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)
J. R. Nield wrote: > On Tue, 2002-07-16 at 15:36, Bruce Momjian wrote: > > > > J.R., just checking to see how PITR recovery is going. Do you need any > > assistance or have any questions for us? > > > > Also, do you have any idea how close you are to having something > > completed? Are you aware we are closing development of 7.3 at the end > > of August and start beta September 1? Is there any way we can help you? > > > > It should be ready to go into CVS by the end of the month. > > That will include: logging all operations except for rtree and GiST, > archival of logfiles (with new postgresql.conf params), headers on the > logfiles to verify the system that created them, standalone backend > recovery to a point-in-time, and a rudimentary hot backup capability. Sounds great. That gives us another month to iron out any remaining issues. This will be a great 7.3 feature! > I could use some advice on the proper way to add tests to configure.in, > given that the autoconf output is in CVS. Would you ever want a patch to > include the generated 'configure' file? We only patch configure.in. If you post to hackers, they can give you assistance and I will try to help however I can. I can so some configure.in stuff for you myself. > Related to that, the other place I need advice is on adding Ted Tso's > LGPL'd UUID library (stolen from e2fsprogs) to the source. Are we > allowed to use this? There is a free OSF/DCE spec for UUID's, so I can > re-implement the library if required. We talked about this on the replication mailing list. We decided that hostname, properly hashed to an integer, was the proper way to get this value. Also, there should be a postgresql.conf variable so you can override the hostname-generated value if you wish. I think that is sufficient. > We also haven't discussed commands for backup/restore, but I will use > what I think is appropriate and we can change the grammar if needed. The > initial hot-backup capability will require the database to be in > read-only mode and use tar for backup, and I will add the ability to > allow writes later. Yea, I saw Tom balked at that. I think we have enough manpower and time that we can get hot backup in normal read/write mode working before 7.3 beta so I would just code it assuming the system is live and we can deal with making it hot-capable once it is in CVS. It doesn't have to work 100% until beta time. > Does this sound like a reasonable timeframe/feature-set to make the 7.3 > release? Sounds great. This is another killer 7.3 feature, and we really need this for greater enterprise acceptance of PostgreSQL. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Do we still need these NOTICEs?
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > One thing I wondered about here -- is it still possible to use a
> > sequence, which is autogenerated by a SERIAL column, as the default
> > value for another table?
>
> Sure, same as before.
>
> > If so, does this create another dependency to
> > prevent dropping the sequence, and hence the original (creating) table also?
>
> As the code stands, no. The other table's default would look like
> nextval('first_table_col_seq')
> and the dependency deducer only sees nextval() and a string constant
> in this.
>
> Someday I'd like to see us support the Oracle-ish syntax
> first_table_col_seq.nextval
> which would expose the sequence reference in a way that allows the
> system to understand it during static examination of a query.
OK, so creator tracks it, and referencers, even in DEFAULT, don't. Good
to know and probably something we need to point out in the release
notes.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote: > Bruce Momjian wrote: > > > From my perspective, when client coders like Dave Page and others say > > they would prefer the flag to the negative attno's, I don't have to > > understand. I just take their word for it. > > do they really love to check attisdropped everywhere ? > Isn't it the opposite of the encapsulation ? > I don't understand why we would do nothing for clients. AFAIK, there is separate work being done on defining SQL99 compatible system views, that most client apps could and should use. But those (few) apps that still need intimate knowledge about postrges' internals will always have to query the original system _tables_. Also, as we have nothing like Oracles ROWNR, I think it will be quite hard to have colnums without gaps in the system views, so we could perhaps have a stopgap solution of adding logical column numbers ( (pg_attribute.attlognum) that will be changed every time a col is added/dropped just for that purpose. - Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
Hannu Krosing <[EMAIL PROTECTED]> writes: > Also, as we have nothing like Oracles ROWNR, I think it will be quite > hard to have colnums without gaps in the system views, so we could > perhaps have a stopgap solution of adding logical column numbers ( > (pg_attribute.attlognum) that will be changed every time a col is > added/dropped just for that purpose. [ thinks... ] I don't believe this would make life any easier, really. Inside the backend it's not much help, because we still have to look at every single attnum reference to see if it should be logical or physical attnum. On the client side it seems promising at first sight ... but the client will still break if it tries to correlate the logical colnum it sees with physical colnums in pg_attrdef and other system catalogs. Bottom line AFAICT is that it's a lot of work and a lot of code to examine either way :-( regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
Hannu Krosing wrote: > > On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote: > > Bruce Momjian wrote: > > > > > From my perspective, when client coders like Dave Page and others say > > > they would prefer the flag to the negative attno's, I don't have to > > > understand. I just take their word for it. > > > > do they really love to check attisdropped everywhere ? > > Isn't it the opposite of the encapsulation ? > > I don't understand why we would do nothing for clients. > > AFAIK, there is separate work being done on defining SQL99 compatible > system views, that most client apps could and should use. > > But those (few) apps that still need intimate knowledge about postrges' > internals will always have to query the original system _tables_. > > Also, as we have nothing like Oracles ROWNR, I think it will be quite > hard to have colnums without gaps in the system views, Agreed. However do we have to give up all views which omit dropped columns ? > so we could > perhaps have a stopgap solution of adding logical column numbers ( > (pg_attribute.attlognum) that will be changed every time a col is > added/dropped just for that purpose. > > - > Hannu -- Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP COLUMN
> > But those (few) apps that still need intimate knowledge about postrges' > > internals will always have to query the original system _tables_. > > > > Also, as we have nothing like Oracles ROWNR, I think it will be quite > > hard to have colnums without gaps in the system views, > > Agreed. However do we have to give up all views which omit > dropped columns ? What's Oracle's ROWNR? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DROP COLUMN
On Wed, 2002-07-17 at 11:29, Christopher Kings-Lynne wrote: > > > But those (few) apps that still need intimate knowledge about postrges' > > > internals will always have to query the original system _tables_. > > > > > > Also, as we have nothing like Oracles ROWNR, I think it will be quite > > > hard to have colnums without gaps in the system views, > > > > Agreed. However do we have to give up all views which omit > > dropped columns ? > > What's Oracle's ROWNR? A pseudocolumn that is always the number of row as it is retrieved. so if we had it, we could do something like select ROWNUM as attlognum, attname from ( select attname from pg_attribute where attrelid = XXX and attisdropped order by attnum ) att order by attlognum; and have nice consecutive colnums the internal select is needed because ROWNUM is generated in the executor as the tuple is output, so sorting it later would mess it up - Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DROP COLUMN
I sent a draft by mistake, sorry. Hannu Krosing wrote: > > On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote: > > Bruce Momjian wrote: > > > > > From my perspective, when client coders like Dave Page and others say > > > they would prefer the flag to the negative attno's, I don't have to > > > understand. I just take their word for it. > > > > do they really love to check attisdropped everywhere ? > > Isn't it the opposite of the encapsulation ? > > I don't understand why we would do nothing for clients. > > AFAIK, there is separate work being done on defining SQL99 compatible > system views, that most client apps could and should use. > > But those (few) apps that still need intimate knowledge about postrges' > internals will always have to query the original system _tables_. > > Also, as we have nothing like Oracles ROWNR, I think it will be quite > hard to have colnums without gaps in the system views, Agreed. However do we have to give up all views which omit dropped columns ? Logical numbers aren't always needed. I think the system view created by 'CREATE VIEW as select * from pg_attribute where not attisdropped' has its reason for existing. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(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
