Scott Marlowe escribió:
> On Thu, Dec 18, 2008 at 10:46 PM, Bryce Nesbitt wrote:
> > I've got a legacy app that does 8.3 incompatible date searches like so:
> > explain select count(*) from contexts where publication_date like '2006%';
> > explain select count(*) from contexts where publication_da
Bryce Nesbitt writes:
> I've got a legacy app that does 8.3 incompatible date searches like so:
> explain select count(*) from contexts where publication_date like '2006%';
> explain select count(*) from contexts where publication_date like
> '2006-09%';
> I've got my choice of refactoring, but a
I am currently using postgresql 8.3 and whenever I want to get the last
inserted ID use :
Select currval(pg_get_serial_sequence(table, field))
Then, I had to downgrade a database for certain customer to use postgresql
8.1, and when I execute that same function I found that
pg_get_serial_sequence
"Sebastian Rychter" writes:
> I am currently using postgresql 8.3 and whenever I want to get the last
> inserted ID use :
> Select currval(pg_get_serial_sequence(table, field))
> Then, I had to downgrade a database for certain customer to use postgresql
> 8.1, and when I execute that same functio
Tom Lane wrote:
Why are you worrying? The old method surely didn't get indexed either.
Continuous improvement?
Since there already IS an index available, I figure I might as well use
it, especially since this DB had real performance issues. The table
itself is medium sized in our world, at
LinkedIn
Mahmoud Ewiwi requested to add you as a connection on LinkedIn:
--
Marcin,
I'd like to add you to my professional network on LinkedIn.
- Mahmoud
View invitation from Mahmoud Ewiwi
http://www.linkedin.com/e/XCcEdFwZmSzO1q19PFca3OmGtD
