On Sun, 2013-03-31 at 15:45 -0400, Tom Lane wrote:
> Really, when we're traipsing down a bucket
> list, skipping over bucket entries with the wrong hash code is just
> about free, or at least it's a whole lot cheaper than applying ExecQual.
>
> Perhaps what we should do is charge the hash_qual_cos
I am not sure if CL is best example - it has no NULL SQL logic.
Current issue is introduced by design, where empty array is similar to NULL
(but not same) - what is on half way to Oracle varchar behave. But it is
not consistent with other data types in postgres.
Regards
Pavel
2013/3/31 Dimitr
Hi,
This patch fix the wrong examples in funcs.sgml introduced by the commit:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a570c98d7fa0841f17bbf51d62d02d9e493c7fcc
regards
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http:/
Peter Eisentraut writes:
> Right, we need to keep libpq in CPPFLAGS, but we can remove it from
> SHLIB_LINK.
Buildfarm member anole says otherwise. I suspected something like that
might happen --- if memory serves, there are platforms where you have to
list all required libraries on the link lin
Heikki Linnakangas writes:
> That's not related to the -R option, the situation with config_file is the
> same with or without it. But yes, if you use config_file option to point
> outside the data directory, the config file won't be backed up. That feels
> intuitive to me, I wouldn't expect it to
Pavel Stehule writes:
> I understand, but I don't agree. W have to fix impractical design of
> arrays early. A ARRAY is 1st class - so there is not possible to use
> varchar2 trick.
>
> if we don't would to use GUC, what do you think about compatible
> extension? We can overload a system functions
Stephen Frost writes:
> * Jeff Davis (pg...@j-davis.com) wrote:
>> In Stephen's case the table was only 41KB, so something still seems off.
>> Maybe we should model the likelihood of a collision based on the
>> cardinalities (assuming a reasonably good hash function)?
> It's not really 'hash coll
On Friday, March 22, 2013, Ants Aasma wrote:
> On Fri, Mar 22, 2013 at 10:22 PM, Merlin Moncure
> >
> wrote:
> > well if you do a non-locking test first you could at least avoid some
> > cases (and, if you get the answer wrong, so what?) by jumping to the
> > next buffer immediately. if the non
Peter Eisentraut writes:
> So here is my updated patch, with the ecpg business changed as explained
> above, and the extra magic removed from the Cflags lines.
No objections to this version.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Fri, Mar 29, 2013 at 11:22 AM, Andres Freund wrote:
> - sepgsql: db_schema:search permission and sepgsql: db_procedure:execute
> permission:
> Not much review afaics.
> => looks unfair, but unless some comitter (robert?) takes it
> on I don't see much alternative to booting it to the ne
On 2013-03-30 23:35:24 -0400, Tom Lane wrote:
> "David E. Wheeler" writes:
> > Hackers, what would be required to get an index on a CITEXT column to
> > support LIKE?
>
> The LIKE index optimization is hard-wired into
> match_special_index_operator(), which never heard of citext's ~~
> operators
Hi,
I moved this patch to the next commit fest.
Thanks,
--
Michael
12 matches
Mail list logo
