On Fri, Aug 31, 2012 at 12:32 AM, Rikard Pavelic wrote:
>
>
> I'm doing something most DBA would probably think it's a bad idea, but at
> least
> I can provide you with use case of Postgres usage.
>
There are bad ideas and there are bad ideas. The question of course is
what you get and what it
On 29.8.2012. 21:02, Merlin Moncure wrote:
> On Wed, Aug 29, 2012 at 10:44 AM, Chris Travers
> wrote:
>
>> Again, the question is simply this:
>>
>> Are the table constraints for storage complete in themselves (and assuming
>> full knowledge of all changes of internal data types) or are they
>> e
On Wed, Aug 29, 2012 at 10:44 AM, Chris Travers wrote:
>> I think there's a lot of circumstantial
>> support for that argument; consider the case of plpgsql declared
>> record variables for example...what happens to them?
>
>
> Again, the question is simply this:
>
> Are the table constraints for
On Wed, Aug 29, 2012 at 6:55 AM, Merlin Moncure wrote:
>
> Yeah -- the question at hand is whether certain table-ish mechanisms
> apply to a table's type when it's used in non-table-storage ways. In
> particular, defaults and constraints are interesting.
> I'm arguing that they don't apply: de
On Tue, Aug 28, 2012 at 11:09 PM, Chris Travers wrote:
> here's my sense from what I've done in this area so far.
>
> On Tue, Aug 28, 2012 at 9:54 AM, Tom Lane wrote:
>>
>> Bruce Momjian writes:
>> > On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote:
>> >> On 13.3.2012. 20:49, Merli
here's my sense from what I've done in this area so far.
On Tue, Aug 28, 2012 at 9:54 AM, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote:
> >> On 13.3.2012. 20:49, Merlin Moncure wrote:
> >>> I personally think it's an oversight. This
Bruce Momjian writes:
> On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote:
>> On 13.3.2012. 20:49, Merlin Moncure wrote:
>>> I personally think it's an oversight. This was just discussed a
>>> couple of days ago here:
>>> http://postgresql.1045698.n5.nabble.com/Altering-a-table-with-
On Mon, Aug 27, 2012 at 9:40 PM, Bruce Momjian wrote:
> On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote:
>> On 13.3.2012. 20:49, Merlin Moncure wrote:
>> > I personally think it's an oversight. This was just discussed a
>> > couple of days ago here:
>> > http://postgresql.1045698.n
On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote:
> On 13.3.2012. 20:49, Merlin Moncure wrote:
> > I personally think it's an oversight. This was just discussed a
> > couple of days ago here:
> > http://postgresql.1045698.n5.nabble.com/Altering-a-table-with-a-rowtype-column-td5544844
On 13.3.2012. 20:49, Merlin Moncure wrote:
> I personally think it's an oversight. This was just discussed a
> couple of days ago here:
> http://postgresql.1045698.n5.nabble.com/Altering-a-table-with-a-rowtype-column-td5544844.html
>
> The server is blocking the alter-not-null-with-default because
On Sat, Feb 25, 2012 at 7:23 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6489
> Logged by: Rikard Pavelic
> Email address: rikard.pave...@zg.htnet.hr
> PostgreSQL version: 9.1.2
> Operating system: Windows 7
> Description:
>
> I'm trying
On Wed, Feb 29, 2012 at 11:40:31AM -0300, Alvaro Herrera wrote:
>
> Excerpts from rikard.pavelic's message of sáb feb 25 10:23:18 -0300 2012:
>
> > But I would expect second alter to pass and enforcing not null and default
> > when adding this column in table and not enforcing not null and defaul
Excerpts from rikard.pavelic's message of sáb feb 25 10:23:18 -0300 2012:
> But I would expect second alter to pass and enforcing not null and default
> when adding this column in table and not enforcing not null and default when
> adding into composite type for another table.
>
> Is this by des
On 28.2.2012. 15:01, Marti Raudsepp wrote:
> On Sat, Feb 25, 2012 at 15:23, wrote:
>> This works:
>> alter table t1 add x float not null;
> Peeking at the code, currently any modifications that cause a rewrite
> of the original table are disallowed.
>
> Adding a nullable column without a default
On Sat, Feb 25, 2012 at 15:23, wrote:
> This works:
> alter table t1 add x float not null;
> This doesn't work:
> alter table t1 add x float not null default 0;
> It fails with ERROR: cannot alter table "t1" because column "t2.j" uses its
> row type
> But I would expect second alter to pass and
The following bug has been logged on the website:
Bug reference: 6489
Logged by: Rikard Pavelic
Email address: rikard.pave...@zg.htnet.hr
PostgreSQL version: 9.1.2
Operating system: Windows 7
Description:
I'm trying to push types in Postgres and have run into some
lim
16 matches
Mail list logo
