"Joe Conway" <[EMAIL PROTECTED]> writes:
> Is the concern that the name-based variants of the function should be called
> like:
>select has_table_privilege(current_user, pg_class, 'insert');
> or
>select has_table_privilege(current_user, "My Quoted Relname", 'insert');
It'd be reall
On Fri, 8 Jun 2001, Mike Cianflone wrote:
> I'm running into some strange behavior with foreign keys which are a
> tuple of primary keys.
>
>
> I have a parent table sector, and a child of that is cell_area table and a
> child of that is unit table.
>
> The cell_area table has a foreign
I'm running into some strange behavior with foreign keys which are a
tuple of primary keys.
I have a parent table sector, and a child of that is cell_area table and a
child of that is unit table.
The cell_area table has a foreign key parent_sector_index referencing same
name in parent t
[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
>> heap_formtuple is for constructing a tuple from scratch. It sounds like
>> you should be using heap_modifytuple instead.
> But I am using SPI_modifytuple(). The rest came from tracing that
> function.
Hm. Looks like the author of SPI_modifytuple
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Clearly it is not the case that "this kluge surprises everyone except
> those who already know it exists."
How can you argue that, when the topic comes up again every couple of
months?
regards, tom lane
--
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have a report from BSD/OS developers that 'make check' fails during
> the initdb stage. Any ideas?
What's left in the logfiles, particularly the postmaster log?
(See src/test/regress/log/)
regards, tom lane
-
Robert Bruccoleri ([EMAIL PROTECTED]) wrote:
> It's not clear to me why the spinlock needs be grabbed at the
> beginning of RelationGetBufferWithBuffer,
I believe you are right: the spinlock doesn't need to be grabbed,
because if a valid buffer is passed in, it must already be pinned
(since the r
"Roberto Abalde" <[EMAIL PROTECTED]> writes:
> I've found that some two functions in /src/backend/optimizer/plan/planner.c
> have side effects.
No kidding ;-). The planner is full of side-effects on data structures.
Both of the changes you mention are intentional.
regard
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> But since the construct is not allowed (or useless), why would
> anyone feel they need to use it?
Because it isn't entirely useless, actually. I agree that no
programmer in his right mind would write, by hand, a comparison
involving NULL, knowing th
Hi people,
I've found that some two functions in /src/backend/optimizer/plan/planner.c
have side effects.
First, I've added two pprints before and after line 89-90 like this.
pprint(parse->rtable);
/* primary planning entry point (may recurse for subqueries) */
result_plan = subquery_planner
[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
> Am I misunderstanding the call? I thought that the nulls parameter was
> to map out which values you were changing to were NULL.
heap_formtuple is for constructing a tuple from scratch. It sounds like
you should be using heap_modifytuple instead.
Mike Mascari <[EMAIL PROTECTED]> writes:
> The best solution would be to have the ODBC translate instances of '=
> NULL' into IS NULL before submitting the query to PostgreSQL.
Does Access only talk to Postgres via ODBC? (Seems plausible, but I
don't know.) What about people copying-and-pastin
I built my own binary RPMs with rpm -bb and this spec file. I compiled
and "installed" postgres using the instructions in comments in the %build
section because I haven't bothered to figure out how %build works. This
installation is roughly based on the RedHat 6.0 SPEC file and probably has
a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
> Some fields may contain line breaks; for example, error messages
> definitely do now.
>>
>> Yes. I believe most of them are set up to indent the continuation
>> lines, so there wouldn't be much of a problem interpreting the format
"Joe Conway" <[EMAIL PROTECTED]> writes:
>> We do not currently have correct implementations of IS TRUE, IS FALSE,
>> or IS UNKNOWN (IS TRUE/FALSE are in there but give the wrong result
>> for null inputs). This is on my to-do list to fix; not sure if the
>> master TODO list mentions it or not.
On Fri, 8 Jun 2001, Jean-Francois Leveque wrote:
>
> I created a Foreign Key (REFERENCES) constraint on
> a table like this (some columns ommited) :
> CREATE TABLE tablename (
> id_tablename INTEGER DEFAULT nextval('id_tablename_seq'),
> tablename_parent INTEGER CONSTRAINT tablenam
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> quotes:
> ... This results in
> a three-valued logic, which has an UNKNOWN in addition
> to TRUE and FALSE. [...] UNKNOWN is a logical value and
> not the same as a NULL, which is a data value.
SQL92 is not very clear about
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Actually I am not sure whether the column = NULL syntax is even defined
> or allowed in SQL92 (e.g. Informix interprets the NULL as column name in
> this context and errs out).
Strictly speaking, SQL92 would require you to write
foo
I created a Foreign Key (REFERENCES) constraint on
a table like this (some columns ommited) :
CREATE TABLE tablename (
id_tablename INTEGER DEFAULT nextval('id_tablename_seq'),
tablename_parent INTEGER CONSTRAINT tablename_parent_fk
REFERENCES tablename (id_tablename),
CONSTRAINT ta
19 matches
Mail list logo
