> > I'm thinking that I should put a 'SearchSysCacheCopy' where my
> @@ comment is
> > to retrieve the attribute by name, and then do a check to see if it's
> > dropped. Is that the best/fastest way of doing things? Seems
> unfortunate
> > to add a another cache lookup in every parsed query...
>
Christopher Kings-Lynne wrote:
> /*
> * Scan the user column names (or aliases) for a match. Complain if
> * multiple matches.
> */
> foreach(c, rte->eref->colnames)
> {
> /* @@ SKIP DROPPED HERE? @@ */
> attnum++;
> OK, my guess is that it is checks in parser/. I would issue each of
> these queries with a non-existant column name, find the error message in
> the code, and add an isdropped check in those places.
OK, I think I've narrowed it down to this block of code in scanRTEForColumn
in parse_relation.c
We have the TODO item:
* Make sure all block numbers are unsigned to increase maximum table size
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 num
Patch applied. Thanks.
---
Manfred Koizar wrote:
> Fix typo in xl_heaptid comment
>
> Servus
> Manfred
>
> --- ../base/src/include/access/htup.h 2002-07-04 18:05:04.0 +0200
> +++ src/include/access/htup.h 200
Gavin, this is not even close to the CVS code. Would you regenerate
based on CVS. I could do it, but you will probably make a more reliable
patch.
---
Gavin Sherry wrote:
> Slight bug in the previous patch. Logically (an
> So I withdraw my earlier comment. But perhaps the syntax of the proposed
> command could be aligned with the CREATE TRANSLATION command.
Ok. What about this?
CREATE CONVERSION
FOR
TO
FROM
DROP CONVERSION
BTW, I wonder if we should invent new access privilege f
Patrick Macdonald wrote:
> The idea of using the last lsn on the page to detect a partial
> write is used by other dbms systems. You already have that
> information available so there is no overhead in computing it.
> Nothing wrong with CRC though.
Agreed. Just thought I would point out that
Tom Lane wrote:
> A conversation in pgsql-interfaces reminded me that it would be a good
> idea for initdb to try to set attnotnull correctly for columns of the
> system catalogs. Although we generally don't recommend that people
> update catalogs directly, it's sometimes done anyway; having NOT
Tom Lane writes:
> A considerable advantage of per-relation constraint names is that a new
> unique name can be assigned for a nameless constraint while holding only
> a lock on the target relation. We'd need a global lock to create unique
> constraint names in the SQL92 semantics.
Presumably,
Tom Lane writes:
> One thing that's really unclear to me is what's the difference between
> a and a , other than
> that they didn't provide a syntax for defining new conversions.
The standard has this messed up. In part 1, a form-of-use and an encoding
are two distinct things that can be appli
Good idea. Patch attached. autoconf run.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Looking at configure.in, it looks pretty safe:
>
> > if test "$ac_env_CXXFLAGS" != set; then
> > if test
A conversation in pgsql-interfaces reminded me that it would be a good
idea for initdb to try to set attnotnull correctly for columns of the
system catalogs. Although we generally don't recommend that people
update catalogs directly, it's sometimes done anyway; having NOT NULL
constraints set on
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Looking at configure.in, it looks pretty safe:
> if test "$ac_env_CXXFLAGS" != set; then
> if test "$GXX" = yes; then
> CXXFLAGS=-O2
> else
> case $template in
> osf)CXXFLAGS='-O4 -Olimit 2000' ;;
> unix
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I guess you mix up SQL99's "trasnlate" and "convert".
No, I believe Peter has read the spec correctly. Further down they have
is a function for changing each character
of a given string according to some many-to-one or one-to-one
Peter Eisentraut wrote:
> > Interesting. I thought -O2 was only set in /template files, but I now
> > see it is set in configure too. The following patch fixes the libpqxx
> > compile problem on FreeBSD/alpha. The old code set -O2 for
> > FreeBSD/i386, but that is already set earlier. The new
> Tatsuo Ishii writes:
>
> > > Also, is there anything in SQL99 that we ought to try to be
> > > compatible with?
> >
> > As far as I know there's no such an equivalent in SQL99.
>
> Sure:
>
> 11.34
I guess you mix up SQL99's "trasnlate" and "convert".
As far as I know, SQL99's "tr
Tom Lane writes:
> As a general rule, anything that affects one *BSD affects them all.
> I am always very suspicious of any patch that changes only one of
> the *BSD templates or makefiles. I'm not even convinced we should
> have separate makefiles/templates for 'em ...
If they could retroactiv
Bruce Momjian writes:
> jtv wrote:
> > On Wed, Jul 03, 2002 at 01:45:56PM -0400, Bruce Momjian wrote:
> > >
> > > Actually, I am confused. In src/template/freebsd I see:
> > >
> > > CFLAGS='-pipe'
> > >
> > > case $host_cpu in
> > > alpha*) CFLAGS="$CFLAGS -O";;
> > > i386*)CFLA
Tatsuo Ishii writes:
> > Also, is there anything in SQL99 that we ought to try to be
> > compatible with?
>
> As far as I know there's no such an equivalent in SQL99.
Sure:
11.34
Function
Define a character translation.
Format
::=
20 matches
Mail list logo
