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
> > > und
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
> > >
> > 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. Ho
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 fo
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 chang
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
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 dep
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 awa
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
"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
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
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 ch
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
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 t
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
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 d
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 p
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
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 thi
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 fu
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
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
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
> >
> > 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 fu
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 ass
> * 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 i
> > 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:
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 w
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 dr
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
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 sca
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 gene
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.
-
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 b
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 infinit
> >> 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
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
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 FU
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 confusi
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 implici
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, th
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
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
--
#===
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
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 i
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
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 t
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
> -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
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 suff
...
> 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 e
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
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 enterin
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.
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 doc
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 t
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
...
> > 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 equatio
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)?
>
>
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
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
"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
> > 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
> us
> 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 likel
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
65 matches
Mail list logo
