It might possibly make sense for a libpq routine that exposes Parse
to actually do Parse followed by Describe Statement; that would allow
it to give back (a) an indication of the number and types of parameters
needed by the statement, and (b) an indication of the column set to be
On Aug 17 2003, [EMAIL PROTECTED] wrote:
Did something changed on today's cvs.
src/template/unixware is wrong on last line: THREAD_CFLAGS += -D_REENTRANT
should be THREAD_CFLAGS=$THREAD_CFLAGS -D_REENTRANT
No it shouldn't
The original patch worked just fine...
I'll look when I get back
On Aug 16 2003, Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Has the idea of putting the infrastructure in place to allow a full
pathname to be fed to DT_SONAME been totally killed?
What makes you think you need new infrastructure? The HPUX port has
used a full-path rpath for
ERROR: update or delete on ftp violates foreign key constraint $1
on ftp
DETAIL: Key (ftp_id)=(11) is still referenced from ftp.
Considering I have several different FTP tables in various schemas, this
message doesn't have much detail. The Error Message Style Guide does
not indicate one way or
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
... If that's
what we think we want, we'd better put it on the wish-list for 7.5.
If we had a Parse function, then we at phpPgAdmin could allow Reports to
contain parameters, and detect as such, and then when they run their report,
they can
in pg is function to_hex () , but there is no function to_dec,
but there could be auto conversion like in c/c++ and others lang.
select 0x64;
select 0312;
( and like in asm select 01010101b; :-)
and also :
select char(0x64);
or conversion :
select '0x64' :: int;
need to change parser ?
ok, but in this use, but when i need to create datatype,
which i use in other tables (to be sure that always is this same)
i need to always writing casting to convert int to int ?
On Sun, 17 Aug 2003, Rod Taylor wrote:
On Sun, 2003-08-17 at 14:30, ivan wrote:
but in real alias_to_int is
Rod Taylor [EMAIL PROTECTED] writes:
Considering I have several different FTP tables in various schemas, this
message doesn't have much detail. The Error Message Style Guide does
not indicate one way or the other whether tables, etc. should be fully
qualified or not. Possibly not in ERROR, but
I said:
Oh, I see what it is. The initial sizing of the hash table (number of
buckets) is done using the planner's estimate of the number of rows out
of the subplan. In your later examples, the hash table is woefully
overloaded and so searching it takes longer (too many items on each
hash
You know how DEFAULT 'now' no longer works? Well, I have some old tables
that still have stuff like DEFAULT 'now' and DEFAULT 'today' in them and
they will be dumped with pg_dump using that default. Does that mean that
mean that when I reload into 7.4, my defaults will no longer work?
Chris
since it's not clear here if the dot is in the name or not. We'd have
to write
ERROR: table schema.foo does not exist
which is just plain ugly.
Yes, it certainly is.
There are error fields defined in the SQL spec for table name, schema
name, etc, and at some point we should
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
You know how DEFAULT 'now' no longer works? Well, I have some old tables
that still have stuff like DEFAULT 'now' and DEFAULT 'today' in them and
they will be dumped with pg_dump using that default. Does that mean that
mean that when I reload
You know how DEFAULT 'now' no longer works? Well, I have some old
tables
that still have stuff like DEFAULT 'now' and DEFAULT 'today' in them and
they will be dumped with pg_dump using that default. Does that mean
that
mean that when I reload into 7.4, my defaults will no longer work?
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Can we ensue that this is listed in the release notes clearly then?
Bruce hasn't made up the incompatibilities to note section yet,
but when he does, it should certainly be mentioned.
regards, tom lane
14 matches
Mail list logo
