On Mon, 2002-07-15 at 06:06, Christopher Kings-Lynne wrote:
We could name the fields dropped_x sort of thing perhaps
In practice that would certainly work, especially if we increase
NAMEDATALEN to 128 or so, as has been proposed repeatedly.
Well, x is just an integer
etc. I put that extra number after dropped and not at the end
so prevent it
being off the end of a 32 character name.
Alternatively, we could invest a lot of work to make it possible for
attname to be NULL, but I don't see the payoff...
Yeah, I think a weird name should be good
However, I'm not happy with the way dropped columns are renamed. I want to
give them a name that no-one would ever want to use as a legit column name.
I don't like this behaviour:
Yes, how about prepending a character that would usually need to be escaped.
I like Hannu's proposal with the
On Mon, 2002-07-15 at 09:20, Christopher Kings-Lynne wrote:
etc. I put that extra number after dropped and not at the end
so prevent it
being off the end of a 32 character name.
Alternatively, we could invest a lot of work to make it possible for
attname to be NULL, but I
I'm trying to use a closed source program with PostgreSQL over ODBC
The problem is that it tries to make a table which has a column called
'cmin' which of course not allowes.
Are there any plans of either
1) (optionally) renaming such sytem columns in the ODBC layer
2) renaming system
On Mon, 15 Jul 2002, Zeugswetter Andreas SB SD wrote:
I would prefer a simple but highly predictable rule, where you can say
Don't name your columns starting with \353\010 (blank, greek d,
BS) over some random algo that stays out of the way by means of low
probability.
\353 is not a delta
Hannu Krosing [EMAIL PROTECTED] writes:
or to make it even more self documenting store the drop time,
col001 [EMAIL PROTECTED]
I'm not at all excited about trying to store times, random numbers,
etc in dropped column names. We are not trying to do cryptography
here, only invent an improbable
OK, more DROP COLUMN funny business:
Assuming that selects, updates and deletes all ignore the dropped column,
what happens with things like alter table statements?
You can still quite happily set the default for a dropped column, etc.
Will I have to add a dropped column check in everywhere
The fmtId() function used in pg_dump for optional quoting identifiers
has bothered me for a while now. The API is confusing: the returned
value needs to be used before fmtId() is called again, because the
buffer the return value points to is re-used for each call of fmtId().
That leads to bugs
Just to give a little background, using pgdump in default mode creates
a dump file that includes inline newlines and tabs. The solution is to
use the -Fc option but it's a little late for that if all one has is a
default dump file. I was hoping to simply run a conversion on the file
to
On Mon, 2002-07-15 at 11:30, Christopher Kings-Lynne wrote:
OK, more DROP COLUMN funny business:
Assuming that selects, updates and deletes all ignore the dropped column,
what happens with things like alter table statements?
You can still quite happily set the default for a dropped
Rod Taylor wrote:
On Mon, 2002-07-15 at 11:30, Christopher Kings-Lynne wrote:
OK, more DROP COLUMN funny business:
Assuming that selects, updates and deletes all ignore the dropped column,
what happens with things like alter table statements?
You can still quite happily set the
Bruce Momjian [EMAIL PROTECTED] writes:
Excellent idea. That's how temp tables worked, by bypassing the
syscache. I wonder if you could just prevent dropped columns from being
returned by the syscache. That may work just fine.
No, it will break all the places that need to see dropped
I see the problem now. It was my file parser that was escaping the value
then passing it to PQescapeString which resulted in \\n instead of \n.
Guess I was on a wild goose chase. I guess PQescapeString() and
PQputline() are mutally exclusive ... my bad!
Thanks,
Marc L.
Tom Lane wrote:
Marc
chris, have you looked at how sapdb (http://www.sapdb.org)
does this ?
/sergio
ps: IANAL
Christopher Kings-Lynne [EMAIL PROTECTED] escribió en el
mensaje [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
OK,
DROP COLUMN now seems to work perfectly. All the old test cases that
failed
now work
Can somebody point me to any escape handlers in the COPY mechanism. I
have grepped and examined to the best of my ability and haven't found
any indication that there even is an escape handler around COPY.
Just to give a little background, using pgdump in default mode creates
a dump file that
An example is:
regression=# create table foo (f1 text);
CREATE TABLE
regression=# insert into foo values ('z');
INSERT 148289 1
regression=# insert into foo select * from foo;
INSERT 148290 1
regression=# insert into foo select * from foo;
INSERT 0 2
regression=# insert into foo
I have added:
AC_CHECK_LIB(getopt, main)
to configure.in to allow PostgreSQL to perhaps find getopt_long() in a
separate library.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard
The following system table columns are currently unused and don't appear
to be in the line of resurrection.
pg_language.lancompiler
pg_operator.oprprec
pg_operator.oprisleft
pg_proc.probyte_pct
pg_proc.properbyte_cpu
pg_proc.propercall_cpu
pg_proc.prooutin_ratio
pg_shadow.usetrace
I've been conversing with Bruce off-list about getting people together
for dinner one night during next week's OSCon in San Diego. Please email
me if you are interested with your preferred day/time and I will try to
coordinate something.
Also FYI there is a PostgreSQL BOF scheduled:
We had a fixed version of getopt() that would properly warn users that
they compiled psql without long options on systems with buggy getopt's,
like FreeBSD.
Now that I have added a search for libgetopt.a, which may find
getopt_long on those platforms, I have removed utils/getopt.c. No
modules
Tom Lane writes:
Also, is the new relfilenode somehow guaranteed to
not be assigned to another relation (pg_class tuple, I think)?
I've been wondering about that myself. We might have to add a unique
index on pg_class.relfilenode to ensure this; otherwise, after OID
wraparound there
Rod Taylor writes:
I've been running a few functions within schema's. It's annoying that
everything needs to be qualified as it doesn't allow the functions to be
moved very easily.
Would it be appropriate for the function to have it's own schema as
pre-pended onto the user path while in
We have src/utils for stuff supposedly that is used by the backend and
other binaries, and src/backend/port for stuff used only by the backend.
However, over time, this distinction has broken down and we have a
number of backend/port stuff used in other binaries. I propose moving
the src/utils
Peter Eisentraut wrote:
Tom Lane writes:
Also, is the new relfilenode somehow guaranteed to
not be assigned to another relation (pg_class tuple, I think)?
I've been wondering about that myself. We might have to add a unique
index on pg_class.relfilenode to ensure this; otherwise,
For all intent and purpose, pg_index.indisprimary can be added to that
list. Can't make a primary key without a pg_constraint entry.
The below are also reported unused by the documentation:
pg_class.relukeys
pg_class.relfkeys
pg_class.relrefs
pg_index.indisclustered
pg_index.indreference
On
Bruce Momjian writes:
I have added:
AC_CHECK_LIB(getopt, main)
to configure.in to allow PostgreSQL to perhaps find getopt_long() in a
separate library.
Is there a system that distributes a libgetopt library that contains
getopt_long()?
--
Peter Eisentraut [EMAIL PROTECTED]
Bruce Momjian writes:
However, over time, this distinction has broken down and we have a
number of backend/port stuff used in other binaries. I propose moving
the src/utils remaining items into src/backend/port, and removing the
src/utils directory.
I propose the reverse operation.
--
Peter Eisentraut wrote:
Bruce Momjian writes:
I have added:
AC_CHECK_LIB(getopt, main)
to configure.in to allow PostgreSQL to perhaps find getopt_long() in a
separate library.
Is there a system that distributes a libgetopt library that contains
getopt_long()?
I have it
Peter Eisentraut wrote:
Bruce Momjian writes:
However, over time, this distinction has broken down and we have a
number of backend/port stuff used in other binaries. I propose moving
the src/utils remaining items into src/backend/port, and removing the
src/utils directory.
I
On Mon, 15 Jul 2002 16:46:44 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
regression=# update foo set f1 = 'qq';
server closed the connection unexpectedly
Same with DELETE FROM foo;
I am not sure if this is a bug introduced by the patch, or if it's
exposed a previously lurking bug.
I suspect the
On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote:
The following system table columns are currently unused and don't appear
to be in the line of resurrection.
pg_language.lancompiler
pg_operator.oprprec
pg_operator.oprisleft
pg_proc.probyte_pct
pg_proc.properbyte_cpu
Hannu Krosing wrote:
On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote:
The following system table columns are currently unused and don't appear
to be in the line of resurrection.
pg_language.lancompiler
pg_operator.oprprec
pg_operator.oprisleft
pg_proc.probyte_pct
On Tue, 2002-07-16 at 04:55, Bruce Momjian wrote:
Hannu Krosing wrote:
On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote:
The following system table columns are currently unused and don't appear
to be in the line of resurrection.
pg_language.lancompiler
pg_operator.oprprec
Hannu Krosing wrote:
The alternative would be yet another system table which would allow us
to support unlimited number of to/from converters for different wire
protocols, but it will definitely be easier to start with
typreceive/typsend.
We can always re-add the columns them.
On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote:
Hannu Krosing wrote:
The alternative would be yet another system table which would allow us
to support unlimited number of to/from converters for different wire
protocols, but it will definitely be easier to start with
Hannu Krosing wrote:
On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote:
Hannu Krosing wrote:
The alternative would be yet another system table which would allow us
to support unlimited number of to/from converters for different wire
protocols, but it will definitely be easier to
On Tue, 2002-07-16 at 05:43, Bruce Momjian wrote:
Hannu Krosing wrote:
On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote:
Hannu Krosing wrote:
The alternative would be yet another system table which would allow us
to support unlimited number of to/from converters for different
From: Tom Lane [EMAIL PROTECTED]
Date: Thu, 02 May 2002 00:45:19 -0400
;;; However, that doesn't explain our OS X problem. I added some debug
;;; printouts, and can now report positively that (a) the fork() call
;;; returns normally in the parent process, providing an apparently-correct
;;;
Hannu Krosing wrote:
Technically this will probably not extend much beyond modifying function
printtup_internal in src/backend/access/common/printtup.c
/*
* printtup_internal
* We use a different data prefix, e.g. 'B' instead of 'D' to
* indicate a tuple in internal
Log message:
This fixes 2 inaccuracies in the recently added SQL99 feature list docs.
UNIQUE and DISTINCT predicates are both listed as implemented -- AFAIK,
neither is.
DISTINCT was implemented a couple of weeks ago. I'll change the docs
again...
- Thomas
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
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.
It looks like our current bit string type
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.
It looks like our current bit string type
OK, I have added comments to \dT and SGML docs to mention that 'line' is
not implemented. This should help future folks.
It would be nice to get the line type working 100%. Thomas says the
problem is input/output format. I don't completely understand.
Peter Eisentraut [EMAIL PROTECTED] writes:
It would be a lot clearer if relfilenode were replaced by an integer
version, starting at 0, and the heap files were named OID_VERSION.
The reason to not do that is that the bufmgr and levels below would now
need to pass around three numbers, not two,
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I agree that a wrapper function is probably an appropriate solution,
but only some of the calls of SearchSysCache should use it.
What like add another parameter to SearchSysCache*?
Definitely *not*; I don't want to kluge up every call to
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I agree that a wrapper function is probably an appropriate solution,
but only some of the calls of SearchSysCache should use it.
What like add another parameter to SearchSysCache*?
Definitely *not*; I don't want to
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
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
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Definitely *not*; I don't want to kluge up every call to SearchSysCache
with a feature that's only relevant to a small number of them.
Uh, then what?
Then we make a wrapper function. Something like
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Definitely *not*; I don't want to kluge up every call to SearchSysCache
with a feature that's only relevant to a small number of them.
Uh, then what?
Then we make a wrapper function. Something like
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.
Well, negative attnums are a good idea and yes, you
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
Christopher Kings-Lynne wrote:
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
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Actually - are you certain that every command uses a SearchSysCache and not
some other weirdness?
They probably don't. You'll have to look closely at places that use the
TupleDesc from a relcache entry.
regards, tom
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...
Chris
---(end of broadcast)---
TIP 1:
Peter Eisentraut wrote:
Bruce Momjian writes:
However, over time, this distinction has broken down and we have a
number of backend/port stuff used in other binaries. I propose moving
the src/utils remaining items into src/backend/port, and removing the
src/utils directory.
I
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:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I did some research on this and generated the following patch. I didn't
find much in the way of problems except two vacuum.c fields that should
probably be BlockNumber. freespace.c also has a numPages field in
FSMRelation that is
Rod Taylor [EMAIL PROTECTED] writes:
For all intent and purpose, pg_index.indisprimary can be added to that
list. Can't make a primary key without a pg_constraint entry.
I disagree. For one thing, there are clients that look at that column.
There's no percentage in breaking them to gain zero
Interesting idea. Not sure how you are going to do that since
appendPQExpBuffer uses vsnprintf. Would you spin through the format
string and modify the pointers sent to vsnprintf? Seems like a lot of
work.
FYI, the 7.2 code had fmtId called pretty messed up in certain places
but I think I
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
For all intent and purpose, pg_index.indisprimary can be added to that
list. Can't make a primary key without a pg_constraint entry.
I disagree. For one thing, there are clients that look at that column.
There's no percentage in
Hannu Krosing [EMAIL PROTECTED] writes:
We can always re-add the columns them.
But would it not be nice if we could add uniform binary protocol without
requiring initdb ?
That won't happen, because the existing contents of those columns are
completely useless for a binary-protocol feature.
I disagree. For one thing, there are clients that look at that column.
There's no percentage in breaking them to gain zero (and it will be
zero, because of alignment considerations...)
Yes, pgaccess uses it, as I remember. Would be nice if it was accurate.
Not to mention phpPgAdmin,
65 matches
Mail list logo
