When we're having an alias discussion, I'd really like to see NVL in
postgres. Not because of porting from oracle as much as just spelling
that without the reference manual is completely impossible.
Best regards,
Marcus
---(end of broadcast)---
Jim C. Nasby wrote:
It might be more useful to look at caching only planning and not
parsing. I'm not familiar with the output of the parsing stage, but
perhaps that could be hashed to use as a lookup into a cache of planned
queries. I suspect that would remove issues of different search_paths.
Martijn van Oosterhout wrote:
But this is of no use in a web-context. According to the docs, this
prepare is per session.
Unless you use something like pgpool, in which case a single session
may include multiple requests.
ok. Good point.
This sql cache I think is a really good thing. Is the
Christopher Kings-Lynne wrote:
> Oracle recently gave some money to Zend to make proper Oracle
support
> for PHP. In that interface they use bind variables. Apart from
greater
> speed, sqlinjection becomes history as well.
I did the same for PostgreSQL for PHP 5.1.
http://
Douglas McNaught wrote:
Which will be the same as the second call. There is quite a big
difference in performance using bind variables.
Does Postgres work the same? Where can I go for more info?
You can do this (or close to it) but you need to explicitly PREPARE
the query (or use the protocol-
Hi list.
I've mostly used Oracle in the past, but for a web-project I took the
opportunity to try Postgres.
When a select is done in Oracle, it first checks if the select is cached
(ie parsed tree, optimizer choices & such). It does this by
[functionality equal to] a byte to byte compare wit
Simon Riggs wrote:
On Thu, 2005-11-03 at 11:13 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On PostgreSQL, CHAR(12) is a bpchar datatype with all instantiations of
that datatype having a 4 byte varlena header. In this example, all of
those instantiations having the varlena header set to 12
