Обсуждение: LONG varsize - how to go on
How I would like to go on:
What I've done so far is to prepare the HeapTuple handling so
it should be possible to reallocate the t_data part from
inside the heap_insert() and heap_update().
Next would be to define how the runtime configuration is to
be stored and configured. So I can get at least the minimum
required system catalog changes made soon. If we leave out
auto-compression for now, a rellongrelid (type Oid default
Invalid) in pg_class, and a attcanlong (type bool default
true) in pg_attribute would do it. This would give space to
enable a single relation for this feature, and then disable
single columns again. New utility commands will finally gain
access to the features. Some scripts will do it during
development, so the feature will not show up - thus beeing
silently unavailable to the user - until we want to ship it.
I think these are the best places to put the configuration
into, because the information would be already available at
no cost inside heap access (rel->rd_rel->rellongrelid and
rel->rd_att...).
What I want to implement for now, is to store extended
VARLENA attributes into a regular (but other relkind)
relation with the Oid key as discussed. That will cause
minimum changes to VACUUM. If storage/retrieval of attributes
is encapsulated right, it could get replaced by something
different at any time in the future when we have enough
experience with this new technique.
Christof Petig and me then could start implementing it, using
lztext with locally disabled compression feature for the
basics. I'll not commit any changes until after feature
freeze of the upcoming release. During the last changes (for
HeapTuple handling) I've seen many places in the code, that
deal themself on VARSIZE/VARDATA with text type attributes,
which then must use textout() instead (what IMHO is better
anyway). So implementing an ALL-varsize move off, instead of
a special LONG datatype, will take longer than February 1st.
This plan means in summary:
1. Full possible configurability with minimum catalog
changes.
2. Hidden without any side effects until we agree to enable
it.
3. Later optimizable storage of extended attributes.
I can't see any reason to way much longer. Can we please have
a consensus to get started?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> How I would like to go on: > > What I've done so far is to prepare the HeapTuple handling so > it should be possible to reallocate the t_data part from > inside the heap_insert() and heap_update(). OK, I assume this is so you can change the tuple size on the fly when inserting the tuple. > > Next would be to define how the runtime configuration is to > be stored and configured. So I can get at least the minimum > required system catalog changes made soon. If we leave out > auto-compression for now, a rellongrelid (type Oid default > Invalid) in pg_class, and a attcanlong (type bool default > true) in pg_attribute would do it. This would give space to > enable a single relation for this feature, and then disable > single columns again. New utility commands will finally gain > access to the features. Some scripts will do it during > development, so the feature will not show up - thus beeing > silently unavailable to the user - until we want to ship it. Got it. You want to store the oid of the long table for the base table inside the pg_class/Relation structure. Good idea. > > I think these are the best places to put the configuration > into, because the information would be already available at > no cost inside heap access (rel->rd_rel->rellongrelid and > rel->rd_att...). > Yes, I recommand a macro so access is clear. See RelationGetRelationName for an example. > What I want to implement for now, is to store extended > VARLENA attributes into a regular (but other relkind) > relation with the Oid key as discussed. That will cause > minimum changes to VACUUM. If storage/retrieval of attributes > is encapsulated right, it could get replaced by something > different at any time in the future when we have enough > experience with this new technique. Good. I recommend calling it pg_* so it is automatically excluded from client table lists. > > Christof Petig and me then could start implementing it, using > lztext with locally disabled compression feature for the I would recommand having compression disabled by default, and enabled by the user. > basics. I'll not commit any changes until after feature > freeze of the upcoming release. During the last changes (for > HeapTuple handling) I've seen many places in the code, that > deal themself on VARSIZE/VARDATA with text type attributes, > which then must use textout() instead (what IMHO is better > anyway). So implementing an ALL-varsize move off, instead of > a special LONG datatype, will take longer than February 1st. OK, so we are going to see this after 7.0 is released, which is fine. I understand the concern about all the accesses to VARDATA() inside the code. That will clearly be difficult. > > This plan means in summary: > > 1. Full possible configurability with minimum catalog > changes. > > 2. Hidden without any side effects until we agree to enable > it. > > 3. Later optimizable storage of extended attributes. > > I can't see any reason to way much longer. Can we please have > a consensus to get started? Sounds good. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote:
> > What I want to implement for now, is to store extended
> > VARLENA attributes into a regular (but other relkind)
> > relation with the Oid key as discussed. That will cause
> > minimum changes to VACUUM. If storage/retrieval of attributes
> > is encapsulated right, it could get replaced by something
> > different at any time in the future when we have enough
> > experience with this new technique.
>
> Good. I recommend calling it pg_* so it is automatically excluded from
> client table lists.
Additionally, exclude them from psql's \dS by looking at the
relkind. And for security reasons, disable regular SELECT for
non-superusers. Also, psql's \d should list the "secondary"
relation name after indices. But that's all stuff far away.
> >
> > Christof Petig and me then could start implementing it, using
> > lztext with locally disabled compression feature for the
>
> I would recommand having compression disabled by default, and enabled by
> the user.
Missed me here. I wanted to abuse lztext during development,
having that only beeing considered for move off at all to get
the in place tuple modification going. Then add all the other
varsize types (there are 12 plus arrays currently) to have
only one source of errors.
> OK, so we are going to see this after 7.0 is released, which is fine. I
> understand the concern about all the accesses to VARDATA() inside the
> code. That will clearly be difficult.
Seems so.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> > > > > > Christof Petig and me then could start implementing it, using > > > lztext with locally disabled compression feature for the > > > > I would recommand having compression disabled by default, and enabled by > > the user. > > Missed me here. I wanted to abuse lztext during development, > having that only beeing considered for move off at all to get > the in place tuple modification going. Then add all the other > varsize types (there are 12 plus arrays currently) to have > only one source of errors. Oh, got it. You are going to implement long tuples for only the lztext type at first. Excellent idea. Did you see someone on the general list already is asking about long tuples for 7.0? I replied on our current status. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote:
> Oh, got it. You are going to implement long tuples for only the lztext
> type at first. Excellent idea. Did you see someone on the general list
> already is asking about long tuples for 7.0? I replied on our current
> status.
I've seen several such questions these days. And I fear, if
I'm not able to get at least the required catalog changes
into 7.0, I'd have to wait until after 7.0 freeze + CVS
branch before I can start at all. That'd cost us too much
time.
I know that I can deal with a bunch of deferred patches,
staying in sync with CURRENT and having new features only as
patches. But that worx only as long as I have most catalog
changes in CURRENT. One single concurrent catalog change can
cost me days of work in the worst case otherwise.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> Bruce Momjian wrote: > > > Oh, got it. You are going to implement long tuples for only the lztext > > type at first. Excellent idea. Did you see someone on the general list > > already is asking about long tuples for 7.0? I replied on our current > > status. > > I've seen several such questions these days. And I fear, if > I'm not able to get at least the required catalog changes > into 7.0, I'd have to wait until after 7.0 freeze + CVS > branch before I can start at all. That'd cost us too much > time. > > I know that I can deal with a bunch of deferred patches, > staying in sync with CURRENT and having new features only as > patches. But that worx only as long as I have most catalog > changes in CURRENT. One single concurrent catalog change can > cost me days of work in the worst case otherwise. The Feb 1 date is not set in stone. If you would prefer March 1, we can look at that option. I pushed for an earlier release because I didn't want to wait for _all_ open items to be completed before a release. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote:
> > I know that I can deal with a bunch of deferred patches,
> > staying in sync with CURRENT and having new features only as
> > patches. But that worx only as long as I have most catalog
> > changes in CURRENT. One single concurrent catalog change can
> > cost me days of work in the worst case otherwise.
>
> The Feb 1 date is not set in stone. If you would prefer March 1, we can
> look at that option.
Let's see how far I can get it in the next 3-4 weeks. Then it
should have turned out if it's worth to delay the release for
another couple of weeks or not.
Had an Idea just as I wrote the (now deleted) text that
appeared here :-)
The problem I wanted to write about are sections (possible,
even if I don't know about one I haven't written myself :-)
in the code, where a Datum is explicitly or implicitly
casted, to get access to vl_len and vl_dat.
Well, I intend to redefine the varlena struct and rename any
macro that deals with it. This way I'll catch any location in
the code, that does anything with variable size attributes in
a usual way.
We wanted to use the top 2 bits of vl_len for flags, leaving
us a theoretical maximum size of 1GB for one single extended
attribute value. Since I want to leave out the compression
part for now, I could set the compression info bit ALLWAYS.
That would force any part of the code, where the above
casting (abuse) occurs, to immediately CRASH at first hit
(would allocate or access >=1G of memory and I think this is
enough to trigger a crash somewhere). If such a setup passes
BETA, I'll feel comfortable with it.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> Bruce Momjian wrote: > > > > I know that I can deal with a bunch of deferred patches, > > > staying in sync with CURRENT and having new features only as > > > patches. But that worx only as long as I have most catalog > > > changes in CURRENT. One single concurrent catalog change can > > > cost me days of work in the worst case otherwise. > > > > The Feb 1 date is not set in stone. If you would prefer March 1, we can > > look at that option. > > Let's see how far I can get it in the next 3-4 weeks. Then it > should have turned out if it's worth to delay the release for > another couple of weeks or not. Yes, let's see how it goes. > > Had an Idea just as I wrote the (now deleted) text that > appeared here :-) > > The problem I wanted to write about are sections (possible, > even if I don't know about one I haven't written myself :-) > in the code, where a Datum is explicitly or implicitly > casted, to get access to vl_len and vl_dat. You will find only a few files that access vl_len/vl_dat, and the rest all use macros. mkid or whatever indexing you use on the source tree will do nicely. The bigger question is going to be handling the VARDATA entries properly when the relate to system tables. The scope of how long that data has to exist may be an issue, and textout() may be the trick in all those cases. The only issue there is pfree'ing the string once your are done with it. > > Well, I intend to redefine the varlena struct and rename any > macro that deals with it. This way I'll catch any location in > the code, that does anything with variable size attributes in > a usual way. Yes, but again, just using mkid or something else will find all of them quickly. Setting the compress bit to catch any unusual cases may be interesting, though I can't see how any routine could get to the varlena data without accessing the field name or macros. > > We wanted to use the top 2 bits of vl_len for flags, leaving > us a theoretical maximum size of 1GB for one single extended > attribute value. Since I want to leave out the compression > part for now, I could set the compression info bit ALLWAYS. > That would force any part of the code, where the above > casting (abuse) occurs, to immediately CRASH at first hit > (would allocate or access >=1G of memory and I think this is > enough to trigger a crash somewhere). If such a setup passes > BETA, I'll feel comfortable with it. Yes, makes sense. Good thing user applications will never see our long pointers. That would be very confusing for them. I am concerned about your trying to continue development on a snapshot while we release the 7.0 release. A single pgindent run will mess you up terribly. I can prevent that, but other work will affect you. I don't want a release to cause you any additional work. Marc is very clear on that. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Setting the compress bit to catch any unusual cases may be interesting,
> though I can't see how any routine could get to the varlena data without
> accessing the field name or macros.
Take a look at NUMERIC or LZTEXT types (both by me and thus I
knew) and you'll know. That's what I meant with implicit
casting.
> I am concerned about your trying to continue development on a snapshot
> while we release the 7.0 release. A single pgindent run will mess you
> up terribly. I can prevent that, but other work will affect you.
Oh - yes! Please don't do a pgindent.
Otherwise it's relatively simple if you know how (screwed up)
I usually work.
First of all, I only use a very limited set of actions while
I'm in my checked out CVS working directory:
cvs update
patch <... (and remove .orig files)
cvs commit
To do a hack, I copy the entire CVS working dir to another
location, configure it and save another copy of the
configured sources into a .orig tree. Then I start hacking,
and if something useful falls out finally, there are two
possible ways depending on the time, the 'hacking' step took:
1. Short (less than 4 hours)
I apply the patch to my CVS working directory and commit
it.
2. Long
I do a 'cvs update', take a copy of it and try to apply
my own patch to that. If it works well down to the
regression test, I can use this patch to apply it to CVS,
otherwise, I need to fix, rediff and start over at 2.
To stay in sync with CURRENT during a long time hack, I just
have to do this:
- Every some days, take a diff of my so far done changes,
- do a 'cvs update',
- take a fresh copy of the CURRENT tree
- and apply my patch onto it.
The last step might show up some rejected hunks, resulting
from conflicting changes by others. Or it might cause other
errors due to conflicts, patch cannot detect. But if doing
these steps frequently enough, the efford to stay in sync
with CURRENT is relatively low.
Someone might think that's a very expensive way of
developing. But over the years, I had good success on long
term hacks with it. And since some folks seem not to agree
with my point of view about using CVS branching for long term
development, it's the only way for me to do it in a similar
way (saving intermediate states of my patches also gives me
the power to start over on an earlier stage).
I assume, some people lost me during the description. But
anyway, I use this for a couple of years now, and it works
fine.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
wieck@debis.com (Jan Wieck) writes:
> Christof Petig and me then could start implementing it, using
> lztext with locally disabled compression feature for the
> basics. I'll not commit any changes until after feature
> freeze of the upcoming release. During the last changes (for
> HeapTuple handling) I've seen many places in the code, that
> deal themself on VARSIZE/VARDATA with text type attributes,
> which then must use textout() instead (what IMHO is better
> anyway). So implementing an ALL-varsize move off, instead of
> a special LONG datatype, will take longer than February 1st.
OK, I feel a lot better about planning this for next release instead
of the Feb-1 release.
It seems like what we ought to be doing in the near term is finishing
up the loose ends that remain with table locking, cache invalidation,
etc. The recently reported "LockRelease" errors seem to fall into
that category as well. Anyway, my point is we ought to go full steam
ahead into cleanup-and-make-ready-for-release mode. Dare I suggest
that we should declare feature freeze *now*, and concentrate on bug
fixes only for the next six weeks? If not, what features are on the
near horizon?
If Bruce wants to run pgindent before the Feb release, maybe the easiest
answer is to do it now (in the next few days) and then Jan can start
working on his new stuff without worrying about it.
regards, tom lane
> It seems like what we ought to be doing in the near term is finishing > up the loose ends that remain with table locking, cache invalidation, > etc. The recently reported "LockRelease" errors seem to fall into > that category as well. Anyway, my point is we ought to go full steam > ahead into cleanup-and-make-ready-for-release mode. Dare I suggest > that we should declare feature freeze *now*, and concentrate on bug > fixes only for the next six weeks? If not, what features are on the > near horizon? > > If Bruce wants to run pgindent before the Feb release, maybe the easiest > answer is to do it now (in the next few days) and then Jan can start > working on his new stuff without worrying about it. I don't need to run pgindent before _every_ release. No problem. I don't see Jan's work chaning what the rest of us focus on. Let's see how it goes. I certainly don't have anything planned. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On 1999-12-18, Tom Lane mentioned: > ahead into cleanup-and-make-ready-for-release mode. Dare I suggest > that we should declare feature freeze *now*, and concentrate on bug > fixes only for the next six weeks? If not, what features are on the > near horizon? What would be the difference between a feature-freeze and a beta then? I'm sure every sane developer wouldn't start anything completely new right now but I for my part still see up to a handful of TODO items that could be fixed with two nights' work each. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On 1999-12-18, Bruce Momjian mentioned:
> I don't need to run pgindent before _every_ release. No problem.
Is this pgindent thing negotiable at all? IMHO the output of plain indent
-orig looks much nicer (and readable). It also tends to look like the bsd
c-style in emacs. If we could just tell people 'set up {emacs|vi|ed} like
this' (such as c-set-style bsd) there wouldn't be half a dozen different
formats propagating through the source until someone comes around with
pgindent.
Btw., I use GNU indent 2.2.1 which is a long way from the versions
pgindent tries to warn about.
More important than arguing about code formatting, however: Could we lose
this a-tab-looks-like-4-spaces thing, now that Bruce has a new editor(?) ?
In any unprepar{ed|able} viewer (cat/more/less/pico) the code looks like
hell. Maybe we could lose the tab altogether because it's a pain. Just
insert 4 (8, 12, ...) spaces.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> On 1999-12-18, Bruce Momjian mentioned:
>
> > I don't need to run pgindent before _every_ release. No problem.
>
> Is this pgindent thing negotiable at all? IMHO the output of plain indent
> -orig looks much nicer (and readable). It also tends to look like the bsd
> c-style in emacs. If we could just tell people 'set up {emacs|vi|ed} like
> this' (such as c-set-style bsd) there wouldn't be half a dozen different
> formats propagating through the source until someone comes around with
> pgindent.
I did not decide on this format myself, but several developers said they
prefer this format, and I do too. I am willing to open the discussion
to see what people would prefer.
The current format does match my C style for non-PostgreSQL projects
too.
I remember clear mention that we did not like:
if () {
}
I see you are writing your shell scripts with that, and am not a fan of
it, but it is only a shell script.
>
> Btw., I use GNU indent 2.2.1 which is a long way from the versions
> pgindent tries to warn about.
Yes, the message was from when GNU indent had stoppped development in
1994 or so, and they bugs never had been fixed. I have no idea how the
new GNU indent is. I am sure it has fixed some of the older bugs, but I
don't know if they added new bugs.
>
> More important than arguing about code formatting, however: Could we lose
> this a-tab-looks-like-4-spaces thing, now that Bruce has a new editor(?) ?
> In any unprepar{ed|able} viewer (cat/more/less/pico) the code looks like
> hell. Maybe we could lose the tab altogether because it's a pain. Just
> insert 4 (8, 12, ...) spaces.
Again, I think everyone liked it at the time, but this may have changed.
Speak up, folks.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
On 18-Dec-99 Bruce Momjian wrote:
> [Charset ISO-8859-1 unsupported, filtering to ASCII...]
>
> I remember clear mention that we did not like:
>
> if () {
>
> }
Figures. that's the only method I do like!
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN - $24.95/mo or less; 56K Dialup - $17.95/mo or less www.pop4.net Online Campground Directory
http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Again, I think everyone liked it at the time, but this may have changed.
>
> Speak up, folks.
I can live with the code layout conventions we have in place; I like K&R
layout better, but not enough to fight about it. It's easy enough to
set up Emacs to handle the style we have.
What I do *not* like is the tab-stops-are-4-spaces convention. As Peter
says, that makes the code look horrible in any tool that can't easily be
adjusted to a nonstandard tab spacing.
My preference would be to use standard 8-space meaning of tabs, but
stick with our current conventions for visible layout of code (4 columns
per logical indent level, etc). That means people contributing code
would need to use editors that understand the difference between a
physical tab character and a logical indent level. I get the impression
that a number of key developers don't use such editors, so maybe
switching over isn't going to be practical.
regards, tom lane
On 1999-12-18, Bruce Momjian mentioned:
> I remember clear mention that we did not like:
>
> if () {
>
> }
>
> I see you are writing your shell scripts with that, and am not a fan of
> it, but it is only a shell script.
What do I know about shell scripting? :)
Seriously though, I didn't use to do that, but I get to like it more every
day ... I was going to look for an example of uglily-formatted code now,
but can't find one. My concern was more about the 4-space-tabs, because a
tab is 8 spaces in the rest of the world. I have no problem with 4 space
indentation and the good old bsd format.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> On 1999-12-18, Bruce Momjian mentioned:
>
> > I remember clear mention that we did not like:
> >
> > if () {
> >
> > }
> >
> > I see you are writing your shell scripts with that, and am not a fan of
> > it, but it is only a shell script.
>
> What do I know about shell scripting? :)
>
> Seriously though, I didn't use to do that, but I get to like it more every
> day ... I was going to look for an example of uglily-formatted code now,
> but can't find one. My concern was more about the 4-space-tabs, because a
> tab is 8 spaces in the rest of the world. I have no problem with 4 space
> indentation and the good old bsd format.
As a workaround, there is a C program I wrote called entab in
pgsql/src/tools/entab. It has a manual page and everything. It does a
good job of converting tabs to any size, or removing all tabs. It does
certain fancy things like prevent tab changes inside quoted strings, and
clip trailing whitespace. That is what I do in my print filters.
I admit our current system is a pain. Our options are:
o go to 8 space tabs and 8 space indentingo go to 8 space tabs and 4 space indentingo keep 4 space tabs and 4 space
indenting
The first option is out. Eight space indenting is a pain, and our code
would look terrible. Eight is just too much and prevents meaningful
indenting.
The second option is your preference. It is easier to print, but
editing the file can be a pain for editors that don't support
different tab/indent values. Also, I like cursoring over tabs, so
having some indents as 4 spaces and some as full tabs give the code a
funny feeling for me.
I print a lot less, and use entab do handle the 4-space issue, so it
seems the best for me.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Tom Lane wrote:
> Dare I suggest
> that we should declare feature freeze *now*, and concentrate on bug
> fixes only for the next six weeks? If not, what features are on the
> near horizon?
Only if the implementation of the temp file buffered deferred
trigger event queue isn't considered a feature, and after I
committed the catalog changes I need to go on with LONG
quietly.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
Bruce Momjian wrote:
> > If Bruce wants to run pgindent before the Feb release, maybe the easiest
> > answer is to do it now (in the next few days) and then Jan can start
> > working on his new stuff without worrying about it.
>
> I don't need to run pgindent before _every_ release. No problem.
>
> I don't see Jan's work chaning what the rest of us focus on. Let's see
> how it goes. I certainly don't have anything planned.
Would be best for me if you can leave out the pgindent run
for this release. I already have some small things as
patches, that I apply to the latest cvs update. And I fear
what's currently discussed about changing 4 column tabstops
would break them completely.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> Bruce Momjian wrote: > > > > If Bruce wants to run pgindent before the Feb release, maybe the easiest > > > answer is to do it now (in the next few days) and then Jan can start > > > working on his new stuff without worrying about it. > > > > I don't need to run pgindent before _every_ release. No problem. > > > > I don't see Jan's work chaning what the rest of us focus on. Let's see > > how it goes. I certainly don't have anything planned. > > Would be best for me if you can leave out the pgindent run > for this release. I already have some small things as > patches, that I apply to the latest cvs update. And I fear > what's currently discussed about changing 4 column tabstops > would break them completely. Got it, no pgindent run. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
wieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>> Dare I suggest that we should declare feature freeze *now*,
> Only if the implementation of the temp file buffered deferred
> trigger event queue isn't considered a feature,
It's obviously a necessary fix. But no one seemed excited about an
early feature freeze anyway, so disregard that comment...
regards, tom lane
wieck@debis.com (Jan Wieck) writes:
> Would be best for me if you can leave out the pgindent run
> for this release. I already have some small things as
> patches, that I apply to the latest cvs update.
Why not do what Vadim is doing for XLOG: commit your changes under
#ifdefs for a symbol that isn't yet defined?
#ifdef LONG_ATTRSnew code
#elseold code
#endif
I think this'd possibly be helpful anyway for study and debugging
purposes, since people could easily see what you've changed and where.
Eventually, after all the dust settles, we can get rid of the #if's
and the old-code fragments.
I don't normally like #ifdef'd patches of this sort, but as a temporary
measure during implementation I think it'd be better than keeping a
private set of files.
> And I fear
> what's currently discussed about changing 4 column tabstops
> would break them completely.
Bruce doesn't want to do that, and I doubt anyone will force the issue
over his veto. But it would be nice to be able to do a pgindent run;
there's a lot of new code in this release.
regards, tom lane
> wieck@debis.com (Jan Wieck) writes: > > Would be best for me if you can leave out the pgindent run > > for this release. I already have some small things as > > patches, that I apply to the latest cvs update. > > Why not do what Vadim is doing for XLOG: commit your changes under > #ifdefs for a symbol that isn't yet defined? > > #ifdef LONG_ATTRS > new code > #else > old code > #endif > > I think this'd possibly be helpful anyway for study and debugging > purposes, since people could easily see what you've changed and where. > Eventually, after all the dust settles, we can get rid of the #if's > and the old-code fragments. I think Vadim had a single entry point that he could control in that way. Not sure Jan has such an entry point. If the stuff goes all over the place, #ifdef can be hard to read as you are coding. However, he may be able to get to a point with his new macros that he can commit the changes and have long handling turned off until he is happy with it. That would be nice so we can test it by just changing the macro. > > I don't normally like #ifdef'd patches of this sort, but as a temporary > measure during implementation I think it'd be better than keeping a > private set of files. > > > And I fear > > what's currently discussed about changing 4 column tabstops > > would break them completely. > > Bruce doesn't want to do that, and I doubt anyone will force the issue > over his veto. But it would be nice to be able to do a pgindent run; > there's a lot of new code in this release. I hope I didn't "veto" it. I just wanted to mention my reasons, and look for other people to vote too. I have Vince, Peter, and Tom who want 8-space tabs and 4-space indents. Because the old standard was voted on by many more people, I need to hear additional votes to change our standard. Jan, can we run a pgindent on the current sources with the current tab size unchanged? I don't think that would affect you very much. However, I can wait until most of your code is committed. I don't normally run pgindent until just before the final release date. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> wieck@debis.com (Jan Wieck) writes: > > Tom Lane wrote: > >> Dare I suggest that we should declare feature freeze *now*, > > > Only if the implementation of the temp file buffered deferred > > trigger event queue isn't considered a feature, > > It's obviously a necessary fix. But no one seemed excited about an > early feature freeze anyway, so disregard that comment... Yes, Tom, I was wondering about your early freeze proposal. If we freeze, we may as well start beta. However, I believe it was you who suggested Feb 1 rather than Jan 1 because you wanted to clean up some things. So, I assume we are scheduled for a Feb 1 beta, and anything Jan can get done by then should be added, including any working implementation of foreign keys or long tuples. It doesn't have to be 100% tested, just working. Testing is for the beta period. And Jan, others are ready to assist you. I didn't understand foreign keys, but I think I have an idea about long tuples. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote:
> I think Vadim had a single entry point that he could control in that
> way. Not sure Jan has such an entry point. If the stuff goes all over
> the place, #ifdef can be hard to read as you are coding.
Sure, there will be some more entry points this time. But as
far as I see up to now, not too many in the beginning. And
for storing values, they're all located in heapam.c.
Since we decided not to create a separate LONG datatype, and
not doing LONG attributes alone (compression at some point
too), I looked for some unique name for it - and found one.
The characters 'toast' did not show up on a case insensitive
grep over the entire CVS tree. Thus, I'll call it
tuple toaster
subsequently. I think there are enough similarities to a
toaster in this case. If you take a bread (tuple) and toast
some of the slices (attributes), anything can work as you
want and it will smell and taste delicious. In some cases,
slices might get burned (occationally hitting an indexed
value), taste bitter and it will stink.
BTW: The idea itself was stolen from toast/untoast, a GSM
voice data compression/decompression tool.
I'll commit some more changes that put in the basics #ifdef'd
out soon.
> > Bruce doesn't want to do that, and I doubt anyone will force the issue
> > over his veto. But it would be nice to be able to do a pgindent run;
> > there's a lot of new code in this release.
>
> I hope I didn't "veto" it. I just wanted to mention my reasons, and
> look for other people to vote too. I have Vince, Peter, and Tom who
> want 8-space tabs and 4-space indents. Because the old standard was
> voted on by many more people, I need to hear additional votes to change
> our standard.
Who uses an editor that cannot distinguish between tabstop
and shiftwidth? And which editors are these - are they useful
for programming at all?
Anyway, I vote for 8-space tabs and 4-space indents too. My
.exrc set's up 4-space tabs actually, and it's a real mess
when editing non-PG sources.
> Jan, can we run a pgindent on the current sources with the current tab
> size unchanged? I don't think that would affect you very much.
> However, I can wait until most of your code is committed. I don't
> normally run pgindent until just before the final release date.
You can do anything you want soon. I intend only to put the
#ifdef'd out calls to the toaster into heapam.c, and create a
new tuptoaster.c in the same location, again all code
#ifdef'd out. From then on, I can work CVS based without any
interference.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> Bruce Momjian wrote: > > > I think Vadim had a single entry point that he could control in that > > way. Not sure Jan has such an entry point. If the stuff goes all over > > the place, #ifdef can be hard to read as you are coding. > > Sure, there will be some more entry points this time. But as > far as I see up to now, not too many in the beginning. And > for storing values, they're all located in heapam.c. Good. > > Who uses an editor that cannot distinguish between tabstop > and shiftwidth? And which editors are these - are they useful > for programming at all? > > Anyway, I vote for 8-space tabs and 4-space indents too. My > .exrc set's up 4-space tabs actually, and it's a real mess > when editing non-PG sources. OK, that tips the scales in favor of 8-char tabs. My micro-emacs can't handle different indent and tab sizes, but that is an old non-X-based editor. I then checked Crisp, my new X editor, and I can't see how to that either. However, I don't do that much coding, so if people want to go for 8-byte tabs and 4-byte indent, we can do that. Any objections on for that? > You can do anything you want soon. I intend only to put the > #ifdef'd out calls to the toaster into heapam.c, and create a > new tuptoaster.c in the same location, again all code > #ifdef'd out. From then on, I can work CVS based without any > interference. Let me know. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026