Hi all,
I've been using PostgreSQL for a couple of high performance projects
recently and have been extremely impressed - much kudos to all involved in
bringing it this far. One thing that is limiting is the lack of fault
tolerance and load balancing.
Anyway, I've recently started lurking on the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Since these functions will primarily be used in building a sort of
> information schema and for querying system catalogs, we should use the
> approach that is or will be used there: character type values contain the
> table name already case-adjusted
On 7 Jun 2001, Tom Ivar Helbekkmo wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
>
> > That's the nature of the hack we're talking about. It's a grammar
> > level hack to turn a specific sequence of tokens (= NULL) into IS
> > NULL due to a client's generated queries.
>
> Aha! Sorry -- I
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Actually I am not sure whether the column = NULL syntax is even
> defined or allowed in SQL92
I've just checked, by reading the relevant paragraphs and studying the
BNF, and the standard says that any comparison of the form X
Y is unknown if
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. I'm
> sure this is how other vendors, like Oracle handle the issue. Well,
> probably sure... :-)
That's the intell
Stephan Szabo <[EMAIL PROTECTED]> writes:
> That's the nature of the hack we're talking about. It's a grammar
> level hack to turn a specific sequence of tokens (= NULL) into IS
> NULL due to a client's generated queries.
Aha! Sorry -- I jumped in late in the discussion without checking
back t
But beforwarned that if you build the package on rpm 3.0.5, the machines
with previous versions of RPM will not be able to install that RPM. So you
will have to upgrade all of your machines (and also install a couple of
libraries, ie. popt and something else or the other). (correct me if I'm
wrong
Tom Lane <[EMAIL PROTECTED]> writes:
> A compromise answer might be to offer a SET variable that selects the
> Microsoft-compatible misimplementation. Would that fly?
I'd say that's the best way to handle stuff like this. If you
implement something that breaks the standard, to be compatible wi
On 7 Jun 2001, Tom Ivar Helbekkmo wrote:
> 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).
>
> He goes
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Lamar Owen wrote:
> >
> > While the advice to pick up the Rawhide 7.1.2 source RPM is sound for a user
> > of RedHat 7.x, unless you have updated to RPM 3.0.5 or greater on your 6.2
> > boxen you won't be able to install the source RPM from Rawhide, si
On Thu, Jun 07, 2001 at 02:46:50PM +0200, Tom Ivar Helbekkmo wrote:
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>
> > Thus it could be, that NULL in "where column = NULL" is not defined
> > to have a special meaning according to SQL92.
>
> The way I interpret Celko's interpretation of
On Thu, 7 Jun 2001, Peter Eisentraut wrote:
> Vince Vielhaber writes:
>
> > I can grant a series of privileges (comma separated) on a series of
> > objects (comma separated) to either a user, group or public NOT a
> > comma separated list of users or groups. Yet at the bottom of the
> > man page
Hannu Krosing <[EMAIL PROTECTED]> ,in message <[EMAIL PROTECTED]>, wrote:
> Robert Forsman wrote:
> >
> > It doesn't help either when your library has
> > bugs that prevent returning an accurate count of rows affected either.
>
> So does it have such bugs ?
Postgres 7 fixed that JDBC bug.
In process of converting a bunch of scripts from sybase to postgresql
I see something that doesn't make much sense..
I can grant a series of privileges (comma separated) on a series of
objects (comma separated) to either a user, group or public NOT a
comma separated list of users or groups. Yet
> > Thus it could be, that NULL in "where column = NULL" is not defined
> > to have a special meaning according to SQL92.
>
> The way I interpret Celko's interpretation of SQL92, that specific
> construct has a meaning; it evaluates to UNKNOWN, thus not to TRUE,
Imho the text refers to a conte
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Thus it could be, that NULL in "where column = NULL" is not defined
> to have a special meaning according to SQL92.
The way I interpret Celko's interpretation of SQL92, that specific
construct has a meaning; it evaluates to UNKNOWN, thus not
> > 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).
>
> I don't have the standard handy, but I do have Joe Celko's book, "Data
> & Databases: Concepts in Practic
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Here is a small list of big TODO items. I was wondering which ones
> people were thinking about for 7.2?
A friend of mine wants to use PostgreSQL instead of Oracle for a large
application, but has run into a snag when speed comparisons looked
good unt
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).
I don't have the standard handy, but I do have Joe Celko's book,
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> A compromise answer might be to offer a SET variable that selects the
>> Microsoft-compatible misimplementation. Would that fly?
> It would for me. I'd rather have the default be the spec correct behavior
> and let people configure their server to fo
> ERROR: blah blah
> CODE: 12345
> LOCATION: some/file.c line NNN
It might be handy to have the LOCATION in the postmaster log,
or make it something that needs to be explicitly switched on.
I do not think it is of general interest to users (most errors
will result from normal
> > Yes, column = NULL should *never* return true according to the spec (it
> > should always return NULL in fact as stated). The reason for breaking
> > with the spec is AFAIK to work with broken microsoft clients that seem to
> > think that =NULL is a meaningful test and generate queries using
> What if I rename the get_seq_name function and move it to
> backend/utils/adt/name.c (and of course change the references to it in
> sequence.c)? Actually, now I'm wondering why nameout doesn't
> downcase and
> truncate.
Because identifiers can be double quoted if you feel like preserving case
23 matches
Mail list logo
