Richard Neill wrote:
I think that the first query ought to succeed, since although priceband is
ambiguous (it could mean either tbl_prices.priceband or
tbl_instruments.priceband), the information in the WHERE clause means that
they are explicitly equal, and so it doesn't matter which one we use.
We
David B. wrote:
8.0.1 doesn't compile to include plpgsql.o so I can't createlang pl/pgsql.
The 8.0.1 compile does create a plpgsql.so; it is installed under
$prefix/lib.
Why don't you guys provide rpms for the major distributions anyway?
http://www.postgresql.org/ftp/binary/v8.0.1/linux/rpms/
-Ne
Dan Black wrote:
Need to rename function parameters, so that their names and table fields
names are unmatched.
I don't really see a way to make the error any more obvious in the
current pl/pgsql implementation, unfortunately.
-Neil
---(end of broadcast)--
Matthew T. O'Connor wrote:
I believe that pg_autovacuum will work with a .pgpass file just like any
libpq based application.
It should, yes. I've applied the attached patch to HEAD and
REL8_0_STABLE that makes the security warning about -P more broad, and
suggests using ~/.pgpass instead.
-Neil
Alvaro Herrera wrote:
I believe on Windows the file is called pgpass.conf instead?
The SGML docs pretty consistently only mention "~/.pgpass" when
referencing this feature, so I didn't bother mentioning the other name
in the pg_autovacuum README. Perhaps someone should fix the SGML docs to
refer
Enrico Weigelt wrote:
BTW: real is an alias to float4 ?
Yes.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
tirny wrote:
any code instructions
***
IF FOUND AND TG_OP = 'UPDATE' THEN
***
END IF;
***
if not found plsql does't break this structure after IF FOUND and proceed
TG_OP = \'UPDATE\', what bring control structures to:
IF FOUND THEN
IF TG_OP = 'UPDATE' THEN
***
END IF;
END IF;
inconveniently,
Mark Dilger wrote:
It appears that any string representation of an interval of length greater
than 76 is rejected. (76 = 51 + 25 = MAXDATELEN + MAXDATEFIELDS). This
appears to be a limitation enforced within function interval_in() in the
file src/backend/utils/adt/timestamp.c
Yeah, this seems bog
Tom Lane wrote:
There are a lot of fixed-size local buffers in that code. The ones
used in output routines seem defensible since the string to be generated
is predictable. The ones that are used for processing input are likely
wrong. OTOH I'm not eager to throw a palloc into each of those code
p
Alexander Volk wrote:
configure: WARNING: you should use --build, --host, --target
checking build system type... i386-portbld-freebsd5.4
checking host system type... i386-portbld-freebsd5.4
checking which template to use... freebsd
checking whether to build with 64-bit integer date/time support...
Tom Lane wrote:
Well, if you allow for whitespace between tokens then it's immediately
clear that there is no fixed upper bound.
Good point -- there is no upper bound on the input string, but since we
skip whitespace, AFAICS this shouldn't affect the requirements for the
size of the working buffe
Tom Lane wrote:
I believe that the reason for the local buffer is to hold a downcased
version of the input, which we can compare to the all-lower-case tables
of relevant keywords.
Well, that's one of the reasons, but not the only one. For example, how
do you parse '17 minutes31 seconds'::interval
Tom Lane wrote:
Sorry, s/downcased/downcased and null-terminated/. I have not read the
parsing code in question lately, but offhand it seems like transferring
one token at a time into a work buffer isn't a completely broken idea...
I wouldn't call it "broken", but I don't see how it could be done
Tom Lane wrote:
I'm too tired to think about this more tonight, but it seems like
the basic point is that we can't just construct a list of pointers
into (a copy of) the original input string.
I think we _can_ do it that way, it's just a question of whether that is
the best approach. I think the s
Herman Bos wrote:
vib=> select * from "bedrag";
ERROR: relation "bedrag" does not exist
Naturally: there is no such table, regardless of case.
vib=> select "BEDRAG" from sancties;
BEDRAG
(0 rows)
Not with the SQL you provided:
neilc=# select "BEDRAG" from sancties;
ERROR: relation "sanc
SzÅcs GÃbor wrote:
# create table foo (bar int, constraint foobar check (true));
CREATE TABLE
# \d foo
Table "public.foo"
Column | Type | Modifiers
+-+---
bar| integer |
Check constraints:
"foobar" CHECK ()
Yeah, I can repro this with current REL7_4_STABLE
Neil Conway wrote:
I think we _can_ do it that way, it's just a question of whether that is
the best approach. I think the solution I outlined before would work
fine: pass the length of the working buffer to ParseDateTime(), and
reject the input only if the parsing process actually req
Tom Lane wrote:
I'm not set on it --- fix it as you suggested.
Attached is a patch that implements this. I'm not especially happy about
the implementation: defining _two_ local macros (that both
doubly-evaluate one of their arguments) is pretty ugly, but I didn't see
a cleaner alternative --
Haluk GUNCER wrote:
fixing permissions on existing directory /usr/local/pgsql/data ... ok
creating directory /usr/local/pgsql/data/global ... ok
creating directory /usr/local/pgsql/data/pg_xlog ... ok
creating directory /usr/local/pgsql/data/pg_xlog/archive_status ... ok
creating directory /usr/l
Tom Lane wrote:
Considering that you're incrementing bufptr inside the macro, it hardly
seems that double-evaluation is a problem: the argument pretty much has
to be a variable. OTOH there is no reason for the input argument to be
treated that way. I'd suggest just one macro [...]
Ah, yeah, t
Haluk GÜNÇER wrote:
I did it with -n option. The generated core file is attached. I hope it
will help.
The core file itself is not much use -- you need to get a stack trace
from the core file (which I can't do, since I don't have the binaries
you built -- or an HPUX system for that matter). Y
Neil Conway wrote:
Ah, yeah, that works. Attached is a revised patch -- I'll apply it
tomorrow barring any objections. I also fixed the semi-colon -- thanks
for the review.
Patch applied to HEAD, REL8_0_STABLE, and REL7_4_STABLE. Thanks for the
report, Mark.
On Mon, 2005-05-30 at 19:36 +0300, Haluk GÜNÇER wrote:
> #0 0x23cf64 in CreatePortal+0x1f4 ()
> (gdb) bt
> #0 0x23cf64 in CreatePortal+0x1f4 ()
> #1 0x23ce28 in CreatePortal+0xb8 ()
> #2 0x19c094 in exec_simple_query+0x194 ()
> #3 0x19daa8 in PostgresMain+0x1520 ()
> #4 0x12f918 in main+0x1e0
Tom Lane wrote:
System catalog lookups generally follow SnapshotNow rules, not MVCC.
So the new function definition is visible as soon as it's committed,
whether you are in a serializable transaction or not.
IMHO this is a bug, or at least not optimal behavior. But per the
discussion on -hacke
Denis Vlasenko wrote:
Symptom: even the simplest query
$result = pg_query($db, "SELECT * FROM big_table");
eats enormous amounts of memory on server
(proportional to table size).
Right, which is exactly what you would expect. The entire result set is
sent to the client and stored in local memo
Denis Vlasenko wrote:
The same php script but done against Oracle does not have this
behaviour.
Perhaps; presumably Oracle is essentially creating a cursor for you
behind the scenes. libpq does not attempt to do this automatically; if
you need a cursor, you can create one by hand.
-Neil
--
On Thu, 2005-11-17 at 13:07 -0800, David Fetter wrote:
> This is still a bug, or at least a big gotcha.
It's not a bug, merely an unimplemented feature. If no one beats me to
it I'll take a look at doing this for 8.2.
-Neil
---(end of broadcast)-
On Thu, 2005-12-15 at 11:09 -0800, Jim Klo wrote:
> I’m having a similar problem:
>
> ERROR: relation with OID 7121526 does not exist
> CONTEXT: SQL statement "SELECT * INTO temp tmp_resourcequeue from
> resourcequeue where timeblockid in (select timeblockid from tmp_timeblock)"
> PL/pgSQL f
On Sun, 2006-01-29 at 17:03 -0800, David Fetter wrote:
> Another followup, this time with the comment done right.
+ /* Disallow the forbidden_delimiter strings */
+ if (strcspn(cstate->delim, BADCHARS) != 1)
+ elog(ERROR, "COPY delimiter cannot be %#02x",
+
On Sat, 2006-01-28 at 20:17 +0100, Peter Eisentraut wrote:
> This bug was reported to Debian. Comments?
AFAICS I fixed this a few weeks ago (post-8.1.2):
http://archives.postgresql.org/pgsql-committers/2006-01/msg00209.php
http://archives.postgresql.org/pgsql-patches/2006-01/msg00139.php
I get
On Mon, 2006-01-30 at 20:45 -0500, Tom Lane wrote:
> You only fixed the bind-parameter case, though, no? The problem is
> still rampant in the PLs.
Right: the bug report was specific to the bind parameter case. Domain
constraints should also be checked before returning values of a domain
type fro
On Sat, 2006-03-18 at 15:35 -0600, Ashley Clark wrote:
> The call to DNSServiceRegistrationCreate in postmaster.c does
> incorrect byte-swapping on the port number which causes the Bonjour
> registration call to fail on Intel Macs.
Thanks for the patch -- applied to HEAD and back branches, back to
On Mon, 2006-03-20 at 14:27 +0530, Dhanaraj M - Sun Microsystems wrote:
> I have fixed a bug which was reported in our mailing group ealier. Can
> anybody tell me how i could test my code and then put back?
I'm not sure what you mean; if you're asking "how do I submit patches
that fix bugs?", sen
101 - 133 of 133 matches
Mail list logo
