On Tue, 2002-07-16 at 11:44, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > The interim solution would be to set typreceive/typsend to NULL if they
> > are the same as typinput/typoutput in CREATE TYPE.
>
> Which still puts you right back at square one. You might as well define
> We actually reverse it on the fly:
>
> test=> \d xx
>View "xx"
>Column | Type | Modifiers
> -+--+---
>relname | name |
> View definition: SELECT pg_class.relname FROM pg_class;
Well, no - that's just dumping out the parsed f
Hannu Krosing <[EMAIL PROTECTED]> writes:
> The interim solution would be to set typreceive/typsend to NULL if they
> are the same as typinput/typoutput in CREATE TYPE.
Which still puts you right back at square one. You might as well define
two new columns that will carry the function names for
On Tue, 2002-07-16 at 11:13, Tom Lane wrote:
> 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
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, pgaccess uses it, as I remember. Would be nice if it was accurate.
>
> Eh? It is, AFAIK.
Oh, I can't remember if it was fixed or broken. Certainly it is nice to
have for apps like pgaccess.
--
Bruce Momjian
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, pgaccess uses it, as I remember. Would be nice if it was accurate.
Eh? It is, AFAIK.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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.
> Also, pg_class.relpages is an int. We don't have unsigned int columns.
Yeah. I had
> > 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 phpPgA
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 featu
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 percentag
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 fix
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 z
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
> > FSMRelatio
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:
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.
>
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: su
"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, t
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 do
> > 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
> 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, y
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 li
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
GetUndeletedColumnBy
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 sys
> 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.
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
Thomas Lockhart wrote:
> 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 t
"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
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
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.
> 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
> 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 t
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
> 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
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 inte
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
;;; ch
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
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 definit
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:
> > > 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 c
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_op
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 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
> pg_proc.p
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
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.
>
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
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.
--
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
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
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
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:
PostgreSQL
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 r
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
Agreed, and with schemas coming in, we are going to break so much stuff
anyway we should remove them.
---
Peter Eisentraut wrote:
> The following system table columns are currently unused and don't appear
> to be in the lin
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 th
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 we
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
pg_type.typprtl
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 drive
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 selec
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
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
>
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
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 c
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
Marc Lavergne <[EMAIL PROTECTED]> writes:
> Just to give a little background, using pgdump in "default" mode creates
> a dump file that includes inline newlines and tabs.
How old a PG release are you using? COPY has quoted special characters
properly for a long time.
re
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 c
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 cr
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 for
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 tha
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 impro
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
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 colums
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 b
> 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 th
73 matches
Mail list logo
